rpmreaper

Panu Matilainen pmatilai at laiskiainen.org
Wed Jun 4 06:55:19 UTC 2008


On Tue, 3 Jun 2008, Steve Grubb wrote:

> On Tuesday 03 June 2008 18:00:35 Till Maas wrote:
>> On Tue June 3 2008, Steve Grubb wrote:
>>> Did we ever fix rpmbuild to gather shell script interdependencies? If
>>> not, a tool like this might think you can remove a package without
>>> realizing that a shell script calls a program in it.
>>
>> The dependencies need to be specified manually in the spec as Requires:,
>> then this won't happen.
>
> Not really. Bash has been patched to to spit out the programs it calls
> (/bin/bash --rpm-requires). So, its a matter of overriding %__find_requires
> to run a program that gathers the information for shell scripts and falls
> back to the old way for others.
>
> No one should have to specify this, it can be automated easily. Without 
> taking shell scripts into account, you run the risk of breaking 
> unspecified requirements.

I wish it were that simple.

"bash --rpm-requires" does a fair job for the impossible task, but it 
produces way too much bogus information and false positives to be 
generally usable as is. A quick check at various scripts found on a stock 
F9 system shows at least these problems:

1) It mistakes functions declared in sourced scripts as executables
2) It mistakes functions used before declared as executables
3) It thinks of sourced scripts as executables
4) It produces hard dependencies for conditional items
5) For most executables, path is unknown

I suppose fixing 1-3) in bash would be possible by scanning all involved 
scripts (sourced or otherwise) for functions before trying to produce the 
dependencies, but I haven't looked at how it does it's business.

4) is pretty much the showstopper. Multiplatform scripts have things like

[ -x /sbin/solaris-specific ] && /sbin/solaris-specific

which turn into executable(/sbin/solaris-specific), which can never be 
satisfied on a linux system. It doesn't have to be even multiplatform, or 
even cross-distro thing, there's more than enough of these kind of 
problems just from dealing with different hardware, compatibility with 
older systems etc. And there's no way to solve this programmatically, 
you'd need to manually filter any bogosities out.

Assuming 1-3) are fixed and ignoring 4), 5) could be dealt with, at least 
to some extent, but it's a big can of worms too. For the dependencies to 
be discoverable by yum & friends, there would have to be matching provides 
for all executable(foo) items bash --rpm-requires produces.

Rpm could automatically add Provides: executable(foo) for any file with 
executable bits on, but it would cause *enormous* bloat of metadata. Rpm 
could be taught to implicitly provide executable(basename) for files that 
have executable bits on, but that won't help yum (or other depsolvers) 
which don't use actual rpm headers but some other metadata that doesn't 
even have the executable information.

If the file permission bits were added to the metadata, then depsolvers 
could fairly reliably figure out how to map executable(foo) requires into 
actual packages, without the hideous bloat of "physically" added 
executable(foo) provides in packages (assuming rpm is taught to deal 
with them too).

So solving 5) should be possible if 1-3) were fixed, but it'd still be 
pretty moot because 4) can't generally be solved (apart from manually 
filtering bogus dependencies, at which point it's hardly "easily 
automated" :)

 	- Panu -




More information about the fedora-devel-list mailing list