providing what they require

[seth vidal]

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