Re: Is RPM now stricter about checking for file conflicts?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxx> 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 -
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test



[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux