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