Bug 131766

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.

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.

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.

I do not think that it is the correct behavior - to allow malformed 
rpm to wipe out the system as a whole.

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.

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.

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.

Being an RHEL user I have to ask, is this madness going into RHEL 3/4?

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.

FC should definitely error on conflicts in order to forcefully
encourage packages to be actually fixed.  I have no opinion about RHEL.

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.

According to bug 137690 it seems this report can be closed WONTFIX ;) .

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.

*** This bug has been marked as a duplicate of 137690 ***

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.

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.