[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: rpmreaper



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 -


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]