Re: Is RPM now stricter about checking for file conflicts?
On 10/27/2012 09:41 PM, Bruno Wolff III wrote: On Sun, Oct 28, 2012 at 00:45:33 +0700, Michel Alexandre Salim sali...@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 - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Is RPM now stricter about checking for file conflicts?
-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. While, granted, these are upstream packaging bugs and those directories should not be owned by the corresponding packages (they are owned by filesystem), is there any reason why the same RPMs install just fine previously? (and if anyone knows who to contact at Google and Oracle's VBox team respectively, that'd be great -- I tried contacting the Music Manager team but the email listed in the RPM bounces, and the support reps that respond through official channels don't even know what Linux is, they sent me screenshot-grabbing instructions for Windows and Mac...) Apologies if this s a dupe, I could only find one relevant thread regarding file conflicts and that's regarding Samba 3 vs Samba 4 - those apply to files whereas the file conflicts here are really about directories. Best regards, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQjB29AAoJEEr1VKujapN65FQH/j/eXNrzJibxhhCGU56+AxLb utmlECmpOL/w5YfT865oXMS6Y0SlhB6L34VShp9fb+AF06cwCWNhpuDZe2FaWP0k +YmwseDFS4002nSofXapHNU1ZQaF3AWwo4heHH2zLzdQusrC7vTQ5dNBM07FhpH/ FRd+kZlCf9PTtVweVxdZx/9GBpq59wbj7YkYDwXJvM23kaYMeadyj5kEWOK4/RXk j8ED1yQQwKrjkFZmCqPolSN5qDebNbKpXejXG/CR1CKf4aLNtF+QivYHER+fLwGN DEhbG8cvZETpJ6+boYsBVlhdKYL/7dPOCR6589tuHEu6E1v0bae0dg4Aq5Lx7F0= =wH1d -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Is RPM now stricter about checking for file conflicts?
On Sun, 2012-10-28 at 00:45 +0700, Michel Alexandre Salim wrote: 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. While, granted, these are upstream packaging bugs and those directories should not be owned by the corresponding packages (they are owned by filesystem), is there any reason why the same RPMs install just fine previously? (and if anyone knows who to contact at Google and Oracle's VBox team respectively, that'd be great -- I tried contacting the Music Manager team but the email listed in the RPM bounces, and the support reps that respond through official channels don't even know what Linux is, they sent me screenshot-grabbing instructions for Windows and Mac...) Apologies if this s a dupe, I could only find one relevant thread regarding file conflicts and that's regarding Samba 3 vs Samba 4 - those apply to files whereas the file conflicts here are really about directories. You'll probably get an answer, but this seems more like a devel@ topic than a test@ one, for the future...or even for the RPM list. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: Is RPM now stricter about checking for file conflicts?
On Sun, Oct 28, 2012 at 00:45:33 +0700, Michel Alexandre Salim sali...@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 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. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
