On Thu, 23 Oct 2008, Ville Skyttä wrote:
On Thursday 23 October 2008, seth vidal wrote:
Yes - if the pkg provides something it requires then the requires can be
removed.
A simple addition to the rpmbuild process to remove these items from the
requires wouldn't hurt.
When I suggested this on rpm-maint a little over a year ago, there were some
objections because that would render rpm's --filerequire less useful/correct
than it is today. Maybe it wasn't implemented because of that or just
because of lack of manpower at the time.
Pruning out automatically generated self-requires is about three lines of
code, couple more to make it configurable. That's not the issue.
http://lists.rpm.org/pipermail/rpm-maint/2007-July/001578.html
The objection is valid per se, --filerequire would suffer (but not become
entirely useless). I wouldn't personally mind inflicting some inaccuracy
into it if the gains are large enough. I got a 7.3% decrease estimate in
overall number of dependencies in Fedora which should be order-of-magnitude
correct (see above post for more details).
FWIW the number of self-requires on Fedora is vastly larger than what
plain upstream rpm would create, due to the patch that generates soname
dependencies from symlinks to dso's. For example:
[pmatilai@localhost ~]$ rpm -q --filerequire cdparanoia-libs
/usr/lib64/libcdda_interface.so R libcdda_interface.so.0()(64bit)
/usr/lib64/libcdda_interface.so.0 R libcdda_interface.so.0()(64bit)
/usr/lib64/libcdda_interface.so.0.10.0 R libc.so.6()(64bit) R
libc.so.6(GLIBC_2.2.5)(64bit) R libc.so.6(GLIBC_2.3)(64bit) R
libc.so.6(GLIBC_2.4)(64bit) R libm.so.6()(64bit) R
libm.so.6(GLIBC_2.2.5)(64bit) R rtld(GNU_HASH)
Of course those would be gone too if self-requires were pruned.
But if this can't be done in rpm(build), it probably can in createrepo as I
don't think something like --filerequire is (or even can be) implemented in
any tools using the metadata.
As it is now, every dependency in a package gets unconditionally recorded,
regardless of where the provider comes from. It's a very straightforward
rule. And yes it causes some unwanted side-effects, such as the one noted
by Bill here
http://lists.rpm.org/pipermail/rpm-maint/2007-July/001580.html and header
bloat. Changing that is possible and even trivial, it just "breaks" fairly
long time rpm behavior and opens up a different can of worms (a
dirt-simple rule comes bunch of special cases). Making it configurable
via macro would push the decision to vendors and packagers, but ...
While speaking of require/provide bloat, Seth's script filters out one
major source of them:
if n.startswith('config('): # these are funky
continue
IMO they're not funky, they're absolutely useless. The idea behind those
is that you can provide alternate configuration for a package, which is
fine and well, except it's very broken by design:
Say you have package foo with some configuration and myconfig-foo with a
custom config for it. The idea is that you can install foo with
--noconfigs but as foo requires (automatically) config(foo), this should
not be possible unless there's another package in the transaction
providing config(foo). Except that the provide is not pruned at runtime
with --noconfigs like it should... But lets imagine it did that: so you
provide your own configuration in the transaction, ie "rpm -Uvh
--noconfigs foo.rpm myconfig-foo.rpm". --noconfigs is a per-transaction
flag, so the config files from myconfig-foo wouldn't be installed either.
Oops. And for this misfeature, every package with a config file in it,
carries an extra provide + require on itself.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
