Bug 602358 - RFE: collapse libc.so.6* requirements to 'highest' version
Summary: RFE: collapse libc.so.6* requirements to 'highest' version
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-09 17:03 UTC by seth vidal
Modified: 2013-07-29 01:59 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-05-26 12:57:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description seth vidal 2010-06-09 17:03:30 UTC
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.

Comment 1 Jeff Johnson 2010-06-10 22:43:42 UTC
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?

Comment 2 Panu Matilainen 2011-05-26 12:57:45 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.