providing what they require
seth vidal
skvidal at fedoraproject.org
Fri Oct 24 19:57:41 UTC 2008
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 at 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
More information about the fedora-devel-list
mailing list