This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 131766

Summary: file conflicts are off
Product: [Fedora] Fedora Reporter: Bill Nottingham <notting>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: anvil, axel.thimm, barryn, dkelson, herrold, i, leonard-rh-bugzilla, me, nphilipp, pnasrat, pri.rhl1, rdieter, redhat-bugzilla, rvokal, scop, stu
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 4.3.2-18 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 14:05:28 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 130887    

Description Bill Nottingham 2004-09-04 01:41:01 EDT
SSIA.
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.