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