[F8/multilib] {,/usr}/{,s}bin64 (was: Split libperl from perl)

[Ralf Corsepius]

On Mon, 2007-04-30 at 14:09 +0200, Axel Thimm wrote:
> On Mon, Apr 30, 2007 at 02:01:29PM +0200, Ralf Corsepius wrote:
> > On Mon, 2007-04-30 at 13:53 +0200, Axel Thimm wrote:
> > > On Sun, Apr 29, 2007 at 07:18:39PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> > > > On Saturday, 28 April 2007 at 13:22, Axel Thimm wrote:
> > > > > On Fri, Apr 27, 2007 at 08:42:03PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> > > > > > You're trying to solve a different problem.
> > > > > 
> > > > > The main issue is that while FC1.92 started by allowing selected libs
> > > > > form i386 to coexist to assist in installing i386 packages for not yet
> > > > > available x86_64 counterparts, it has evolved to more and more libs,
> > > > > even for stuff that none will really be interested to install the i386
> > > > > part of, and even for developing i386 on x86_64.
> > > > > 
> > > > > So the problem domain slovly changes and multilib is not adequate to
> > > > > serve the needs. We either need to admit that and reduce the specs to
> > > > > what multilib can do on paper and also fix the issues in
> > > > > implementation, or find a better solution that serves the changed
> > > > > demand.
> > > > > 
> > > > > That's what this is all about, and given the bad history of multilib
> > > > > support in rpm, a solution that does not involve any fiddling with
> > > > > rpm, yum, anaconda, smart, apt, ... is preferred.
> > > > 
> > > > rpm needs fixing not to allow conflicting files in {,/usr}/{,s}bin be
> > > > installed.
> > > 
> > > Actually rpm did that before multilib was added, so in fact your
> > > request to "fix" rpm means to remove multilib support.
> 
> > rpm complaining about conflicting programs in {,/usr}/{,s}bin doesn't
> > affect multilibs at all.
> 
> Before multilib support in rpm, the current packages would fail like
> 
> foo.i386 and foo.x86_64 conflicting files in /usr/bin/foo
> 
> and not allow coinstallation. The multilib support made these
> conflicts go away for elfcolored files and made x86_64 silently win
> over i386 in the undone conflicts.

Agreed, this likely is a bug.

But a /usr/bin/foo being provided by foo.i386 and foo.x86_64 with 
and not conflicting otherwise (e.g. in libs underneath) should not be a
problem.

Ralf