i386 junk on x86_64 default install

[Hans de Goede]

Rex Dieter wrote:
> Benny Amorsen wrote:
> 
>>>>>>> "JK" == Jesse Keating <jkeating at redhat.com> writes:
>> JK> Works for me every time. The only shared files that may get
>> JK> removed are documents (bug that needs to be fixed but not
>> JK> critical)
>>
>> Why are files belonging to several packages ever removed, before the
>> last package is gone?
> 
> It shouldn't, and that's why it's a bug. (:
> http://bugzilla.redhat.com/140055

Yes and a bug that needs fixing, its also here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209306

Where I've suggested a reasonable workaround, the problem is that
currently rpm doesn't check if  a file has multiple owners but just
removes it if a package owning it gets removed, when this file is under
one of the following dirs:
    _skip("/usr/share/zoneinfo"),
    _skip("/usr/share/locale"),
    _skip("/usr/share/i18n"),
    _skip("/usr/share/doc"),
    _skip("/usr/lib/locale"),
    _skip("/usr/src"),
    _skip("/lib/modules"),


This is known as the skipdirs patch, which was added because otherwise
rpm's resident mem usage when doing rpm -e on a kernel when you have say
20+ kernels installed could become over 1Gig, which is a but of a
problem on 512Mb or less machines.

The real fix for this would be to fix rpm's absurd mem usage in this
scenarion but that isn't easily doable, thus I've suggested to reduce
the skipdirs list to:
    _skip("/usr/share/zoneinfo"),
    _skip("/usr/share/i18n"),
    _skip("/usr/lib/locale"),
    _skip("/usr/src"),
    _skip("/lib/modules"),

Notice how the following 2 dirs where removed from the list:
    _skip("/usr/share/locale"),
    _skip("/usr/share/doc"),

Removing these 2 dirs is unlikely to trigger the Gig memusage scenario
again, while at the same time reducing the impact of this problem to
almost zero.

Unfortunately nobody sofar has responded to my suggestion to as an
intermediate solution remove these 2 dirs from the skipdirs list, thus
reducing the impact of this bug to almost 0.

Regards,

Hans