providing what they require

[Panu Matilainen]

On Fri, 24 Oct 2008, seth vidal wrote:
> 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.

Note "breaks", not breaks. Bigger "breakage" happens when somebody sets 
"%define _use_internal_dependency_generator 0" in their spec: it just 
means bunch of information doesn't exist in the package at all. Some of it 
is actually important (file colors), large amount of it is used by nothing 
at all, it's just "information". Much like changelogs are - nothing in the 
world *needs* them, but they're nice to have for humans. Except in the 
case of file requires and bunch of other stuff, it's exposed directly in 
the API. Not that it matters that much because nothing can depend on that 
data as it might not be there (rpm v3 packages, packages built using 
external dep generator), so those API's are practically unused...

And back to the self-requires: --filerequire becomes inaccurate if they're 
removed. Fedora doesn't care, somebody else seems to do... for performing 
partial package installations (which is not very "rpm" activity if you ask 
me), and doing dependency graphs on files (which OTOH seems fairly 
reasonable).

If we add an option to rpm to ditch self-requires, should we actually add 
a switch to disable generation of per-file dependency data completely with 
it, maybe link the two options to one? Yum and the like wont notice a 
thing, and it'll make packages & their metadata a little bit smaller.

Self-requires are just the tip of the iceberg when it comes to "useless
bloat" in headers, try the following for entertaining lesson on what sort
of junk the headers carry:
$ rpm -qa --qf "%{name}-%{version}\n[\t%{CLASSDICT}\n]\n"

One of my favorites:
         PNG image data, 313 x 225, 8-bit/color RGBA, non-interlaced
         PNG image data, 339 x 210, 8-bit/color RGBA, non-interlaced
         PNG image data, 349 x 274, 8-bit/color RGBA, non-interlaced
         ...

Rpm knows not only that it's image data, it even knows the picture
dimensions... That a file is an image (or a font, executable, dso ...)
might actually be useful information even in rpm context, it's dimensions
and color encoding probably not. Oh and btw, this file class and file
require/provide information is loaded into memory on installation despite
nothing using it (amounting to ~5-10% of memory use in the case I
tested, and yes I'm going to do something about it).

If you want to get filosophical about it: what is an rpm package and what 
information should it carry and what not? From depsolver POV, pretty much 
all it needs is lists of files and external dependencies. Depsolvers don't 
*need* info like "upstream URL" and changelogs either.

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

I don't think anybody uses it because it's pretty much impossible to use 
as designed. There's a reason --noconfigs is a hidden cli switch unlike 
--excludedocs...

 	- Panu -