[Rpm-maint] [PATCH] drop rtld(GNU_HASH) hack
pmatilai at laiskiainen.org
Wed Sep 17 09:30:17 UTC 2014
On 09/17/2014 11:49 AM, Thierry Vignaud wrote:
> On 17 September 2014 09:35, Panu Matilainen <pmatilai at laiskiainen.org> wrote:
>>> The attached patch drops the drop rtld(GNU_HASH) hack
>> The patch does much more than drop a couple of lines:
>> $ diffstat no-rtld_GNU_HASH_req.diff
>> lib/tagexts.c | 54
>> tools/elfdeps.c | 8 --------
>> 2 files changed, 54 insertions(+), 8 deletions(-)
>> That aside...
> argh, sorry two patches got merged.
> (too much undersleeping due to baby caring :-) )
> Of course, I only intented to submit you the elfdeps bits
>>> Drop automatically generated rtld(GNU_HASH) dependencies.
>>> It's been provided by glibc for 7 years now and can safely be assumed
>>> that there's no longer any need for it, reducing ~5K packages'
>>> dependency in repository metadata on it during next rebuild.
>> ... NAK, distros where GNU_HASH is not supported are still widely deployed
>> (RHEL/Centos <= 5 and no doubt Suse Enterprise versions of that era).
> Seriously :-) ?
> rpm-4.12+ on RHEL5.x :-) ?
> It's using rpm-188.8.131.52. Even RHEL6 is stuch at rpm-4.8
> I don't think they could install a package from a GNU_HASH aware package
> due to the different payload compressor or due to new lib deps.
I'm not expecting anybody to run rpm 4.12 on rhel-5, but building
packages for an older distro is not an uncommon scenario, payload
compressor, file digests etc are configurable items. And rpms have this
funny way of floating around to places where they're not expected. I
just rather err on side of caution, dropping these deps is hardly any
win for rpm.
> Anyway that would be a
>> I guess we could add a cli-switch to allow easily disabling it, but then
>> repository metadata is better trimmed and filtered in createrepo (it already
>> does this for rpmlib() dependencies etc)
> Not everybody uses createrepo :-)
> We use genhdlist2 in Mageia.
Then filter in genhdlist2. There's tonnes of more junk to filter with
bigger gains, such those rpmlib() dependencies in every package,
redundant libc.so version symbols, probably config() dependencies... The
world looks quite different from repodata vs individual package POV,
packages are full of "redundant" dependencies because one cannot go
assuming things at rpmbuild level.
And like said, I'd be okay with adding a switch to optionally disable
the rtld() dependency.
> Also note that whereas less deps in repo metadata is nice for deps solvers,
> less deps in package headers is also nice for rpm when checking/ordering
> the transaction.
> I won't pretend if will shape a new future but it's an easy low fruit
Dep checking/ordering never was a major bottleneck in rpm, thats not an
- Panu -
More information about the Rpm-maint