The FC3 Release Notes say:
============= RPM's default behavior regarding file conflicts in Fedora Core 3 has changed. In the past, file conflicts (where a file from one already-installed package also appears in a package that is to be installed) caused the installation of the package containing the conflicting file to abort.
In Fedora Core 3, RPM will ignore such conflicts, and the package installation will proceed, overwriting any conflicting files from previously-installed packages. ============
What's the rationale for this?
Dax
On Sat, Oct 30, 2004 at 01:20:58AM -0600, Dax Kelson wrote:
In Fedora Core 3, RPM will ignore such conflicts, and the package installation will proceed, overwriting any conflicting files from previously-installed packages.
Is there any way to revert to the previous behaviour ?
Emmanuel
On Sat, 2004-10-30 at 10:27 +0200, Emmanuel Seyman wrote:
On Sat, Oct 30, 2004 at 01:20:58AM -0600, Dax Kelson wrote:
In Fedora Core 3, RPM will ignore such conflicts, and the package installation will proceed, overwriting any conflicting files from previously-installed packages.
Is there any way to revert to the previous behaviour ?
rpm --fileconflicts
Paul
Le samedi 30 octobre 2004 à 11:40 +0100, Paul Nasrat a écrit :
On Sat, 2004-10-30 at 10:27 +0200, Emmanuel Seyman wrote:
On Sat, Oct 30, 2004 at 01:20:58AM -0600, Dax Kelson wrote:
In Fedora Core 3, RPM will ignore such conflicts, and the package installation will proceed, overwriting any conflicting files from previously-installed packages.
Is there any way to revert to the previous behaviour ?
rpm --fileconflicts
Any advice for yum, apt, up2date ?
Paul
On Sat, 2004-10-30 at 12:45 +0200, Matias Féliciano wrote:
Le samedi 30 octobre 2004 à 11:40 +0100, Paul Nasrat a écrit :
On Sat, 2004-10-30 at 10:27 +0200, Emmanuel Seyman wrote:
On Sat, Oct 30, 2004 at 01:20:58AM -0600, Dax Kelson wrote:
In Fedora Core 3, RPM will ignore such conflicts, and the package installation will proceed, overwriting any conflicting files from previously-installed packages.
Is there any way to revert to the previous behaviour ?
rpm --fileconflicts
Any advice for yum, apt, up2date ?
All doable via the api by setting prob filter flags, this may only affect rpm CLI - so they may not be changed depending on if the reset all the flags and just set them for the transaction.
I'll create a simple testcase and confirm against the apps next week.
Paul
Le samedi 30 octobre 2004 à 11:49 +0100, Paul Nasrat a écrit :
On Sat, 2004-10-30 at 12:45 +0200, Matias Féliciano wrote:
Le samedi 30 octobre 2004 à 11:40 +0100, Paul Nasrat a écrit :
On Sat, 2004-10-30 at 10:27 +0200, Emmanuel Seyman wrote:
On Sat, Oct 30, 2004 at 01:20:58AM -0600, Dax Kelson wrote:
In Fedora Core 3, RPM will ignore such conflicts, and the package installation will proceed, overwriting any conflicting files from previously-installed packages.
Is there any way to revert to the previous behaviour ?
rpm --fileconflicts
Any advice for yum, apt, up2date ?
All doable via the api by setting prob filter flags, this may only affect rpm CLI - so they may not be changed depending on if the reset all the flags and just set them for the transaction.
I'll create a simple testcase and confirm against the apps next week.
Does this means, the intend is only to affect rpm(8) (the program) and not other programs ?
Paul
On Sat, 2004-10-30 at 11:40 +0100, Paul Nasrat wrote:
On Sat, 2004-10-30 at 10:27 +0200, Emmanuel Seyman wrote:
On Sat, Oct 30, 2004 at 01:20:58AM -0600, Dax Kelson wrote:
In Fedora Core 3, RPM will ignore such conflicts, and the package installation will proceed, overwriting any conflicting files from previously-installed packages.
Is there any way to revert to the previous behaviour ?
rpm --fileconflicts
So we've got a reply from an @redhat.com that says how to avoid the behavior. But we haven't heard what the reason for the change was. There's been some times on my x86_64 when such an approach might have been nice, but otherwise I just don't understand it.
On Saturday 30 October 2004 11:06, Stuart Jansen wrote:
On Sat, 2004-10-30 at 11:40 +0100, Paul Nasrat wrote:
rpm --fileconflicts
So we've got a reply from an @redhat.com that says how to avoid the behavior. But we haven't heard what the reason for the change was. There's been some times on my x86_64 when such an approach might have been nice, but otherwise I just don't understand it.
I agree - maybe an explanation would help us understand this but so far it sounds insane. I have to maintain a environment for 400 developers that all require root (through sudo) for their work... Unfotunately that means that they sometimes go ahead and install their own packages - I can bet you, the day after this change goes in, the number of systems broken by installing incompatible or bad packages will go from 1 or two a week to dozens... The only thing that saves us right now is file conflicts...
Peter.
Stuart Jansen wrote:
On Sat, 2004-10-30 at 11:40 +0100, Paul Nasrat wrote:
On Sat, 2004-10-30 at 10:27 +0200, Emmanuel Seyman wrote:
On Sat, Oct 30, 2004 at 01:20:58AM -0600, Dax Kelson wrote:
In Fedora Core 3, RPM will ignore such conflicts, and the package installation will proceed, overwriting any conflicting files from previously-installed packages.
Is there any way to revert to the previous behaviour ?
rpm --fileconflicts
So we've got a reply from an @redhat.com that says how to avoid the behavior.
I have to agree with the consensus shown here that this change in default behavior is, to put in mildly, *just plain stupid*. Please, please revert to previous, proper behavior, and force folks who insist on this broken behavior to use rpm --replacefiles
Has anyone bothered to submit anything to bugzilla yet? (If not, I'd be happy to).
-- Rex
On Sat, 2004-10-30 at 12:42, Rex Dieter wrote:
I have to agree with the consensus shown here that this change in default behavior is, to put in mildly, *just plain stupid*. Please, please revert to previous, proper behavior, and force folks who insist on this broken behavior to use rpm --replacefiles
Agreed, wholeheartedly. Hell, why bother with rpm at all, if this is the default. I might as well switch a DIY linux and just install from tarball. Without an explanation, or maybe a pointer to the a discussion on rpm-list (is that hosted at Red Hat?), this just seems like someone was smokin' crack.
On 10/30/2004 11:44:07 AM, Paul Iadonisi wrote:
On Sat, 2004-10-30 at 12:42, Rex Dieter wrote:
Without an explanation, or maybe a pointer to the a discussion on rpm-list (is that hosted at Red Hat?), this just seems like someone was smokin' crack.
I don't *see* any discussion on the rpm list. I think it's a bug.
On Sat, 2004-10-30 at 18:58 +0000, Michael A. Peters wrote:
On 10/30/2004 11:44:07 AM, Paul Iadonisi wrote:
On Sat, 2004-10-30 at 12:42, Rex Dieter wrote:
Without an explanation, or maybe a pointer to the a discussion on rpm-list (is that hosted at Red Hat?), this just seems like someone was smokin' crack.
I don't *see* any discussion on the rpm list. I think it's a bug.
It isn't a bug in Red Hat's eyes if they mention it in the release notes. But I have filed a bug report about it. I have also already set alias rpm='rpm --fileconflicts' in /etc/zshrc.
On 10/30/2004 12:53:50 PM, Nathan G. Grennan wrote:
On Sat, 2004-10-30 at 12:22 -0700, Nathan G. Grennan wrote:
alias rpm='rpm --fileconflicts' in /etc/zshrc.
Because rpm is a weird combination of multiple commands with a wrapper adding --fileconflicts with an alias doesn't work in all cases.
Then we need to file a bug report that rpm does not have a reliable way to turn this behaviour off.
On Sat, Oct 30, 2004 at 09:01:14PM +0000, Michael A. Peters wrote:
Then we need to file a bug report that rpm does not have a reliable way to turn this behaviour off.
mv /usr/bin/rpm /usr/bin/rpm.foobar echo "rpm --fileconflicts $@" > /usr/bin/rpm chmod +x /usr/bin/rpm
Doesn't do squat for the API, though. I'm with the majority, here. Revert.
Emmanuel
Hi,
On Sat, 2004-10-30 at 21:22, Nathan G. Grennan wrote:
Wow. Never seen such a consensus on this list. These kind of poor decisions are good for the team spirit :) .
Default behaviour has been reverted to the good old default of failing on file conflicts. See comment 2 of the above bug report.
Leonard.
On Sun, 31 Oct 2004, Leonard den Ottolander wrote:
Hi,
On Sat, 2004-10-30 at 21:22, Nathan G. Grennan wrote:
Wow. Never seen such a consensus on this list. These kind of poor decisions are good for the team spirit :) .
Default behaviour has been reverted to the good old default of failing on file conflicts. See comment 2 of the above bug report.
JBJ just added the following comment to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131766
Dams: Packages not built by rpm-4.2 or later lack file coloring within the package. Without the proper elf32/elf64 markers within package metadata, the file conflict resolution rule Always prefer elf64. will fail because (duh!) the information is not contained within the package. The symptom will show up as a file conflict, when in actuality, information necessary for rpm to resolve elf file conflicts is not present.
Adding support for multilib is going to increase the incidence of file conflicts dramatically, as the intent is (and was) differing content on the same path for executables, but different /lib /lib64 paths for libraries.
So my comment was directed at missing information, not the quality of 3rd party distro packaging. For better or worse, there are lots of copies of rpm deployed everywhere that are earlier than rpm-4.2, and producing packages that will show up as file conflicts when installed on a multilib system.
That was (and is) the rationale for defaulting file conflict behavior to off, as no one, certainly not me, can control what version of rpm is used to build packages in the wild. The intent was specifically not to remove file conflict detection, but rather change the default, with a --fileconflicts option.
Adding support for both elf32/elf64 packages requires markers to distinguish elf32 from elf64 without reading the payload twice, as that would be a major performance lose.
Whether it is wise to install differing content like elf32 and elf64 on the same path (as multilib does) is an entirely different issue.
And no matter whether file conflict detection is disabled or enabled by default is not the core issue. RPM behavior has changed to do Always prefer elf64. file conflict resolution automagically in order to merge elf32 and elf64 distros without rebuilding or otherwise changing packages (like putting markers within *.spec) at all. The format change is both forward and backward compatible for all non-multilib installs.
And note that much better package selection and file conflict resolution policies are going to be needed (if multilib is truly the wave of the future) than Always prefer elf64. because a) there are non-elf file conflicts that are not addressed. b) elf64 was chosen because only elf64 ldconfig could handle both elf32 and elf64 at the time of implementation (RHL 9).
There are certainly other, better, policies that can be conceived. My guess and hope is that one or the other of the elf32/elf64 distros will be a clear winner after a rather longish transition, in which case all the multilib support will became moot.
I still think it is the wrong answer but feel free to add comments to the bug as applicable.
Tom
Thank you, Jeff, for this detailed information on why this was done. But thank you most of all for changing the default back for FC3.
I am a little surprised that a change with potentially serious negative consequences was never mentioned on fedora-test-list or fedora-devel-list, but only showed up just recently in the release notes so close to release of FC3. Even though the actual change was made earlier in the cycle, no one noticed because of the nature of the change.
Your explanations make sense, but the timing was bad.
A real solution for multi-lib systems truly seems difficult, but the problem should be solvable. Perhaps fedora-devel-list is good forum for that, but maybe rpm-list will suffice. I plan on subscribing to that list. Don't know how much help I can be, but I'll try. I don't yet, but will probably soon have an Opteron system to help (at a minimum) test with.
On Sun, 2004-10-31 at 09:36 -0500, Paul Iadonisi wrote:
I am a little surprised that a change with potentially serious negative consequences was never mentioned on fedora-test-list or fedora-devel-list, but only showed up just recently in the release notes so close to release of FC3.
I'm a little bit surprised that such a major change wasn't noticed until it was documented.
Even though the actual change was made earlier in the cycle, no one noticed because of the nature of the change.
You're right, to notice such a change would require to test something, to use rpm to install some packages, to break smth even. Maybe no one is using rpm these days anymore ;)
I propose to completely remove rpm from repository ;-)
On Sun, 31 Oct 2004 20:11:44 +0200, Mircea MITU wrote:
On Sun, 2004-10-31 at 09:36 -0500, Paul Iadonisi wrote:
I am a little surprised that a change with potentially serious negative consequences was never mentioned on fedora-test-list or fedora-devel-list, but only showed up just recently in the release notes so close to release of FC3.
I'm a little bit surprised that such a major change wasn't noticed until it was documented.
As pointed out earlier, some users noticed it when they installed packages which were supposed to cause conflicts. However, the majority of testers works with clean packages, which don't conflict. And only if a package were expected to conflict, you would notice when it installs without errors instead. Or if you encounter a case where package installation overwrites files and damages the system. I've installed, erased and upgraded many packages (including Fedora Extras packages) during the Fedora Core 3 test period, and all were clean enough not to cause any conflicts.
And frankly, would you expect such a mad change in RPM behaviour?
Would be interesting to know who has payed attention to the rpm package changelog all the time and was aware of the change when it was activated.
On Sun, Oct 31, 2004 at 07:56:57PM +0100, Michael Schwendt wrote:
Would be interesting to know who has payed attention to the rpm package changelog all the time and was aware of the change when it was activated.
(Maybe I'm just tooting my own horn with this post but I'll go ahead and post it anyway, just in case it turns out to be informative and not egotistical.)
I saw the changelog entries at the time, but they were terse enough that I didn't quite pick up on the consequences. Later, I stumbled upon the new behavior. I was going to report it as a bug, but I browsed through Bugzilla first and found bug 131766: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=131766
Since it sounded like an intentional change and it was very late in the dev cycle by the time I fully realized what was going on, I decided to focus on getting it documented rather than changed. Therefore, I filed bug 137033: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137033
And that's how the change got documented in the release notes in the first place...
-Barry K. Nathan barryn@pobox.com
On 10/31/2004 10:11:44 AM, Mircea MITU wrote:
I'm a little bit surprised that such a major change wasn't noticed until it was documented.
Probably because most people using a test release either use a repository tool, and if they build their own rpm's - they use the proper switch (ie -Uh opposed to ih).
On Sun, 2004-10-31 at 09:36 -0500, Paul Iadonisi wrote:
A real solution for multi-lib systems truly seems difficult, but the problem should be solvable. Perhaps fedora-devel-list is good forum for that, but maybe rpm-list will suffice. I plan on subscribing to that list. Don't know how much help I can be, but I'll try. I don't yet, but will probably soon have an Opteron system to help (at a minimum) test with.
I have plenty of ppc64 machines to hand, on which I often run all of ppc64, ppc32 and i386 binaries. I'm more than willing to help test any proper multilib solution which attempts to solve the problem coherently.
man, 01.11.2004 kl. 09.52 skrev David Woodhouse:
On Sun, 2004-10-31 at 09:36 -0500, Paul Iadonisi wrote:
A real solution for multi-lib systems truly seems difficult, but the problem should be solvable. Perhaps fedora-devel-list is good forum for that, but maybe rpm-list will suffice. I plan on subscribing to that list. Don't know how much help I can be, but I'll try. I don't yet, but will probably soon have an Opteron system to help (at a minimum) test with.
I have plenty of ppc64 machines to hand, on which I often run all of ppc64, ppc32 and i386 binaries. I'm more than willing to help test any proper multilib solution which attempts to solve the problem coherently.
Err... i386 binaries on ppc64? wtf? emulation?
On Mon, 2004-11-01 at 16:50 +0100, Kyrre Ness Sjobak wrote:
I have plenty of ppc64 machines to hand, on which I often run all of ppc64, ppc32 and i386 binaries. I'm more than willing to help test any proper multilib solution which attempts to solve the problem coherently.
Err... i386 binaries on ppc64? wtf? emulation?
Yep, in qemu. You can even set up binfmt_misc to recognise i386 ELF binaries and invoke qemu automatically -- even acroread inside a mozilla window with mozplugger works.
On 10/30/2004 12:20:58 AM, Dax Kelson wrote:
What's the rationale for this?
I do not like it. I suspect that there is a setting that can change it, but I haven't looked yet.
I want to know of conflicts, and I do not want the package manager to overwrite a file from another package or earlier version.
Le samedi 30 octobre 2004 à 01:20 -0600, Dax Kelson a écrit :
The FC3 Release Notes say:
============= RPM's default behavior regarding file conflicts in Fedora Core 3 has changed. In the past, file conflicts (where a file from one already-installed package also appears in a package that is to be installed) caused the installation of the package containing the conflicting file to abort.
In Fedora Core 3, RPM will ignore such conflicts, and the package installation will proceed, overwriting any conflicting files from previously-installed packages. ============
Very poor decision. If Red Hat need this "feature" for up2date, Red Hat should add it to up2date only.
man rpm : there is no --noreplacefiles option. man yum : nothing.
Dnia 10/30/2004 10:47 AM, Użytkownik Matias Féliciano napisał:
Very poor decision.
I agree. Yesterday I was playing with kdewebdev and quanta packages. Installing them in wrong order makes quanta broken :/
RPM should not allow to do such a things...
On Sat, 30 Oct 2004 01:20:58 -0600, Dax Kelson wrote:
The FC3 Release Notes say:
============= RPM's default behavior regarding file conflicts in Fedora Core 3 has changed. In the past, file conflicts (where a file from one already-installed package also appears in a package that is to be installed) caused the installation of the package containing the conflicting file to abort.
In Fedora Core 3, RPM will ignore such conflicts, and the package installation will proceed, overwriting any conflicting files from previously-installed packages. ============
What's the rationale for this?
So, --force is default now? :-O
Above text was not included in FC3 Test3. I find it strange to hear about such changes after a freeze.
Hi Michael,
On Sat, 2004-10-30 at 11:15, Michael Schwendt wrote:
So, --force is default now? :-O
Above text was not included in FC3 Test3. I find it strange to hear about such changes after a freeze.
Terrible decision, terrible timing.
Leonard.
On Sat, 2004-10-30 at 01:20 -0600, Dax Kelson wrote:
The FC3 Release Notes say:
============= RPM's default behavior regarding file conflicts in Fedora Core 3 has changed. In the past, file conflicts (where a file from one already-installed package also appears in a package that is to be installed) caused the installation of the package containing the conflicting file to abort.
In Fedora Core 3, RPM will ignore such conflicts, and the package installation will proceed, overwriting any conflicting files from previously-installed packages. ============
What's the rationale for this?
The url below seems to give a clue.
Le samedi 30 octobre 2004 à 13:02 -0700, Nathan G. Grennan a écrit :
-------------------------------------- Additional Comment #2 From Jeff Johnson (jbj@redhat.com) on 2004-09-04 13:52 ------- FIxed in rpm-4.3.2-2.
Please note that the default behavior in rpm is going to become ignoring file conflicts because of the volume of 3rd party, non-RedHat, not built by rpm-4.2 or later, that can/will not install correctly on a multilib machine. --------------------------------------
From rom http://fedora.redhat.com/about/objectives.html
Non-Objectives of Fedora Core: - Being a dumping ground for _unmaintained_ or _poorly designed software_.
The new behaviour is a bug.
On 10/30/2004 01:12:16 PM, Matias Féliciano wrote:
The new behaviour is a bug.
I absolutely 100% agree. If a third party wants their software to work with red hat/fedora then the third party needs to make their software integrates with red hat/ fedora and not the other way around.
Supplying compatability libraries is imho fine. But creating a scenario where your operating is more likely to have a problem because a vendor doesn't have the will to build their src.rpm on the system they intend the package to be installed (thus using the modern rpm) on is just absolutely bonkers and is the WRONG thing for red hat/fedora to do.
Laziness should not be encouraged. If a third party vendor is having difficulty getting their rpm to build on current fedora/red hat then the 3rd party vendor needs to fix their spec file.
Le samedi 30 octobre 2004 à 20:58 +0000, Michael A. Peters a écrit :
On 10/30/2004 01:12:16 PM, Matias Féliciano wrote:
The new behaviour is a bug.
I absolutely 100% agree. If a third party wants their software to work with red hat/fedora then the third party needs to make their software integrates with red hat/ fedora and not the other way around.
FC2 and 4KSTACK is interesting. Fedora (or Linux) break the compatibility with NVidia driver and this annoyed many people.
At the end, this decision (4KSTACK) improve Linux and "free" Linux. Fedora and Linux should not depend on third party.
Supplying compatability libraries is imho fine. But creating a scenario where your operating is more likely to have a problem because a vendor doesn't have the will to build their src.rpm on the system they intend the package to be installed (thus using the modern rpm) on is just absolutely bonkers and is the WRONG thing for red hat/fedora to do.
red hat (RHEL) is a supported product dedicated to Enterprise. It have to work "out of the box". So, I don't know if it's the wrong thing to do for RHEL.
Laziness should not be encouraged. If a third party vendor is having difficulty getting their rpm to build on current fedora/red hat then the 3rd party vendor needs to fix their spec file.
Or rpm may add a warning : Ooops : conflict file detected. Contact the maintainer of the package. Conflict files can be ignored with "--replacefiles".
Le samedi 30 octobre 2004 à 23:20 +0200, Matias Féliciano a écrit :
Le samedi 30 octobre 2004 à 20:58 +0000, Michael A. Peters a écrit :
Supplying compatability libraries is imho fine. But creating a scenario where your operating is more likely to have a problem because a vendor doesn't have the will to build their src.rpm on the system they intend the package to be installed (thus using the modern rpm) on is just absolutely bonkers and is the WRONG thing for red hat/fedora to do.
red hat (RHEL) is a supported product dedicated to Enterprise. It have to work "out of the box". So, I don't know if it's the wrong thing to do for RHEL.
Given the quality of some of the "enterprise" third-party rpms out there you certainly do not want to lighten install-time checks.
They're already doing unholy ops that may hose your system, when this change reaches RHEL I predict a whole world of broken installs RH support will have to rescue.
Cheers,
On Sat, 30 Oct 2004 20:58:29 +0000, Michael A. Peters wrote:
On 10/30/2004 01:12:16 PM, Matias Féliciano wrote:
The new behaviour is a bug.
I absolutely 100% agree. If a third party wants their software to work with red hat/fedora then the third party needs to make their software integrates with red hat/ fedora and not the other way around.
Ack. Those 3rd parties can ask their users to --replacefiles install their packages and explain why they find it necessary to overwrite existing files.
Le samedi 30 octobre 2004 à 01:20 -0600, Dax Kelson a écrit :
The FC3 Release Notes say:
============= RPM's default behavior regarding file conflicts in Fedora Core 3 has changed. In the past, file conflicts (where a file from one already-installed package also appears in a package that is to be installed) caused the installation of the package containing the conflicting file to abort.
In Fedora Core 3, RPM will ignore such conflicts, and the package installation will proceed, overwriting any conflicting files from previously-installed packages. ============
What's the rationale for this?
From rom : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137690
Additional Comment #2 From Jeff Johnson (jbj@redhat.com) on 2004-10-31 03:29 ------- File conflicts reenabled by default in rpm-4.3.2-18.
devel@lists.stg.fedoraproject.org
-
Barry K. Nathan -
David Woodhouse -
Dawid Gajownik -
Dax Kelson -
Emmanuel Seyman -
Féliciano Matias -
Kyrre Ness Sjobak -
Leonard den Ottolander -
Michael A. Peters -
Michael Schwendt -
Mircea MITU -
Nathan Grennan -
Nicolas Mailhot -
Paul Iadonisi -
Paul Nasrat -
Peter Arremann -
Rex Dieter -
Stuart Jansen -
Tom Diehl