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
