Red Hat Bugzilla – Full Text Bug Listing
|Summary:||file conflicts are off|
|Product:||[Fedora] Fedora||Reporter:||Bill Nottingham <notting>|
|Component:||rpm||Assignee:||Jeff Johnson <jbj>|
|Status:||CLOSED DUPLICATE||QA Contact:|
|Version:||rawhide||CC:||anvil, axel.thimm, barryn, dkelson, herrold, i, leonard-rh-bugzilla, me, nphilipp, pnasrat, pri.rhl1, rdieter, redhat-bugzilla, rvokal, scop, stu|
|Fixed In Version:||4.3.2-18||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-21 14:05:28 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Bill Nottingham 2004-09-04 01:41:01 EDT
Comment 2 Jeff Johnson 2004-09-04 13:52:38 EDT
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. Detecting (and failing) an install because of a file conflict is no longer sufficient to meet rpm customer expectations imho. LIFO behavior, already in rpm, is the correct default behavior in general. Yes, specific failure cases will need to be handled specifically. I will make a macro, and Red Hat can choose to disagree by configuring differently in redhat-rpm-config.
Comment 3 Bill Nottingham 2004-09-06 17:00:27 EDT
Differing the package manager install/upgrade behavior based on the presence of a separate package (used for build config) doesn't really seem practical to me - while the change could be in Red Hat's specific RPM config, I don't think it should be in redhat-rpm-config.
Comment 4 Dams 2004-10-30 16:54:41 EDT
I'm just curious : what's that "volume of 3rd party non-RedHat, not built by rpm-4.2 or later, that can/will not install correctly on a multilib machine" you're talking about? Is that criticism against major Fedora 3rd party repositories like fedora.us, freshrpms, rpm.livna.org, dag [...] ? I dont think it's fair since we all do our best to avoid conflicts and to bring the best packages we can do. Or is there is a so much amount of packages out there like the ati-fglrx one from ATI ? Can you name some ? What's the % ratio compared to Valid rpms ? If you keep this behaviour, then rpms become as useful as simple tar files. Should we turn the Fedora Project into a Slackware-like ? Please, Jef, simply drop this "no conflicting file" stuff. It's definitly not what rpm users want.
Comment 5 Paul P Komkoff Jr 2004-10-30 17:50:35 EDT
I do not think that it is the correct behavior - to allow malformed rpm to wipe out the system as a whole.
Comment 6 Nils Philippsen 2004-10-30 18:32:31 EDT
Jeff, what's the name of the macro and where do I need to set it (system-wide)? This should probably be mentioned in the release notes as well (a'la "this is how to revert to the old behaviour"). TIA.
Comment 7 Paul Iadonisi 2004-10-30 18:38:34 EDT
So was this bug been closed? Whether or not Jeff can be convinced that the file conflict behavior should be reverted in rpm proper, I think it's a bad idea for Red Hat to ship with that as the default. Please reenable file conflicts before release of FC3. Users arent' going to be thrilled about having to reenable this for every box they install.
Comment 8 Alan Cox 2004-10-30 18:54:49 EDT
There is certainly a clear consensus for FC3 that the default shoulkd be to error on conflicts, that also gets them fixed. RHEL is quite a different thing here.
Comment 9 Tom Diehl 2004-10-30 19:05:15 EDT
Being an RHEL user I have to ask, is this madness going into RHEL 3/4?
Comment 10 Paul Iadonisi 2004-10-30 19:13:13 EDT
Personally, I'd be even *more* pissed off if I was a paying RHEL customer. If third party rpms need to be rebuilt with post a rpm-4.2 release, then I'd expect that vendors be contacted and advised of that fact before the release of RHEL4, especially if 'rpmbuild --rebuild' is all that is needed. Turning off file conflicts is not a fix. It's barely even a sensable workaround.
Comment 11 Warren Togami 2004-10-30 19:19:15 EDT
FC should definitely error on conflicts in order to forcefully encourage packages to be actually fixed. I have no opinion about RHEL.
Comment 12 Leonard den Ottolander 2004-10-31 05:11:00 EST
Yet another vote against ignoring file conflicts. I have nothing against an system wide option to enable ignoring file conflicts for those who need this, but it should not be the default. I don't want some poorly designed 3rd party rpm to destroy my system by overwriting files it shouldn't.
Comment 13 Leonard den Ottolander 2004-10-31 05:33:32 EST
According to bug 137690 it seems this report can be closed WONTFIX ;) .
Comment 14 Leonard den Ottolander 2004-10-31 05:46:05 EST
Sorry. Read the above as a request instead of a bug report. The original solution as RAWHIDE is a bit confusing wrt this. Should probably have been WONTFIX then instead. Behaviour has been reverted. Good. Closing RAWHIDE.
Comment 15 Warren Togami 2004-10-31 05:51:28 EST
*** This bug has been marked as a duplicate of 137690 ***
Comment 16 Jeff Johnson 2004-10-31 08:49:18 EST
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.
Comment 17 Red Hat Bugzilla 2006-02-21 14:05:28 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.