On Fri, 2008-10-24 at 11:21 +0300, Panu Matilainen wrote:
Pruning out automatically generated self-requires is about three
lines of
code, couple more to make it configurable. That's not the issue.
Let's do this, then. :)
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.
which sounds fine, then.
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 ...
Explain to me what it breaks in terms of backward compat? I'm thinking
that maybe for F11-cycle it could be worth breaking that compat.
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.
Do we have a single case of something using config() in fedora?
Hell, ANYWHERE? any distro at all?
If not then maybe this is a feature that can take a long walk off a
short pier?
-sv