RFE: collapse libc.so.6* requirements to 'highest' version

[Jeff Johnson]

Tracker

[seth (seth-redhat-bugs)]

After a long discussion with notting and others we figured out that we could collapse out a lot of duplicate requirements from pkgs if we collapsed the libc.so.6* requirements to the highest symbol version.

(just piping the libc.so.6 requirements to sort and taking the last one in the output) then we'd reduce total requires metadata in rawhide by 17%.

I can provide a patch for find-requires if it would help.

[Jeff (jeff-redhat-bugs)]

You claim "17% of requires metadata" as if that were relevant. The actual
reduction in _HEADER_ metadata and *.rpm package sizes is far far smaller.

And if you _REALLY_ want to reduce rpm _HEADER_ metadata size, compressing headers will
lead to significant savings that far outweigh filtering a few Requires:
dependencies from *.rpm packages.

There's nothing whatsoever stopping you from filtering whatever you choose
to include in repo-metadata, where a a reduction in primary.xml _IS_ likely
significant. But that is no rpm issue.

The real flaw in yum is repeatedly downloading repo-metadata as a monolithic
blob of _EVERYTHING again and again and again and again. But that (of course)
is irrelevant in a RPM bugture/featlet report, isn't it?

[Panu (panu-redhat-bugs)]

WONTFIX, createrepo collapses them for repodata which is where the bigger win (for yum) is.

Besides not being much of a win in the actual headers, there are other issues as well:
- the symbol versions present real data that can help protecting against broken builds (think of some older version symbol vanishing on a busted glibc build)
- this would cause --filerequire/--fileprovide breakage (remember rpm collects this data per-file), and even if only highest dependency per file was collected, the there would be "duplicates" as the symbol versions can and do vary between files within a package
- symbol versions aren't reliably sortable in general (glibc-ones /might/ be but I wouldn't bet my life on it) so it'd be a glibc-specific hack, and we're trying to /eliminate/ such things instead of adding more.