providing what they require

[Panu Matilainen]

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 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.

> 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 -