fedora12 oddity

[Thierry Parmentelat]

Sorry for the hassle, but.. the patch you pointed me at could not be reversed as-is from the f18 rpm code
So I had to cook my own, I take it this is straightforward but I'd feel safer if you could quickly review that :)

Thanks in any case -- Thierry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mine.patch
Type: application/octet-stream
Size: 1027 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20130204/9667cbbd/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: original.patch
Type: application/octet-stream
Size: 1846 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20130204/9667cbbd/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rpmfi-f18.c
Type: application/octet-stream
Size: 34689 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-list/attachments/20130204/9667cbbd/attachment-0005.obj>
-------------- next part --------------



On Feb 2, 2013, at 2:18 PM, Panu Matilainen wrote:

> On 02/02/2013 02:32 PM, Thierry Parmentelat wrote:
>> Hi there
>> 
>> Following up on a scenario (an f14 physical box spinning off guests from fedora12 to fedora18), I've noticed something a bit off
>> 
>> * in the official f12 repo (I know, I know, this is totally out-of-lived, but please stay with me for a second) I've found that glibc-common *and* filesystem were providing the same file(directory actually) entry '/usr/lib/locale'
>>  see below for the details
>> 
>> * as I've explained in another post, this f14 box tuns out to run a custom rpm version, rebuilt essentially after the one that comes with f18
>> 
>> * the funny thing is, although this f12 repository worked quite fine of course with the f12 rpm, with this f18-ish rpm I get this error when trying to build an f12 filesystem:
>> 
>> Transaction Check Error:
>>  file /usr/lib/locale conflicts between attempted installs of filesystem-2.4.30-2.fc12.i686 and glibc-common-2.11.2-3.i686
> 
> The directory permissions (most likely access bits but could be user/group too) differ between the packages. Older rpm versions were sloppy here and permitted this, but rpm >= 4.10 requires exact match of permissions for a shared file/directory.
> 
>> 
>> I'm considering various options to work around that - like, rebuilding the filesystem rpm so that it does not (stupidly) expose this empty dir, but I thought maybe there is something simpler than that, like an option to this recent rpm to get backward compatibility ?
> 
> There's no compatibility workaround for this in rpm, except the sledgehammer approach of --replacefiles. Rebuilding the filesystem package to either fix the permissions to match those of glibc or omit the directory is probably the path of least pain.
> 
> Or alternatively, since you're already using a custom rpm on the host, revert this patch:
> http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=cf1095648194104a81a58abead05974a5bfa3b9a
> 
> 	- Panu -
> _______________________________________________
> Rpm-list mailing list
> Rpm-list at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-list