On Wed, 2008-10-29 at 10:05 +0200, Panu Matilainen wrote:
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...
I'd bet it is more than 'practically unused' but completely unused. In
fact, if there are users of the rpm api that we don't know about I'd be
a little surprised. rpm package management development is a fairly small
world :)
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.
Can you give me an example of per-file dep data that I might need? Just
to see where we might break compat/expected behavior in an odd way.
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).
Niiiiiiiiiiiiiice.
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.
Some of this data is useful for making subtle distinctions when
depsolving. Yum does odd things when there are multiple providers to
score up a package based on things like sourcerpm. :)
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...
Then maybe a set of things to have missing from rpm in F11?
-sv