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