FC3 rpm behavior change

[Tom Diehl]

On Sun, 31 Oct 2004, Leonard den Ottolander wrote:

> Hi,
> 
> On Sat, 2004-10-30 at 21:22, Nathan G. Grennan wrote:
> > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137690
> 
> 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