Is RPM now stricter about checking for file conflicts?

[Panu Matilainen]

On 10/27/2012 09:41 PM, Bruno Wolff III wrote:
> On Sun, Oct 28, 2012 at 00:45:33 +0700,
>    Michel Alexandre Salim <salimma at fedoraproject.org> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Ever since I started tracking Fedora 18, Google Music Manager is no
>> longer installable, and now Oracle's Virtual Box cannot be installed
>> either (both from upstream Yum repositories).
>>
>>  https://bugzilla.redhat.com/show_bug.cgi?id=870655
>>
>> In both cases, RPM and yum aborts with file conflicts -- /lib/modules
>> for VirtualBox and /usr/bin for google-musicmanager.
>
> It is stricter for F18 or F19, but I am only aware of checks for meta
> data (timestamps I think) being stricter. I don't know if that is what

Just FWIW, timestamps do not and in reality, can never cause a conflict, 
otherwise sharing (generated) content between eg multilib packages would 
be impossible in practise.

> you are seeing though. I saw some packages that had conflicts on one
> fedora release not have them on another, even though it was the same
> version (there hadn't been a build for the newer release). I don't
> remember if the difference was between F17 and F18 or F18 and F19 though.

The exact difference between rpm >= 4.10 (ie Fedora >= 18) and older is 
that differing file/directory permissions (mode, user- and groupname) 
are considered a conflict now. This is how it always should've been, but 
the change is disruptive enough (as witnessed here) that existing Fedora 
etc releases are better left alone.

	- Panu -