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 -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
