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

[Axel Thimm]

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. With which I
agree 100%, because that only inflicted pain.

> Current multilib allows you to run 32bit apps, for example
> googe-earth as well as develop/debug other 32bit software. That's
> good enough for me and I suspect for many people as well. Now if
> only yum wouldn't try to install both package.i386 and
> package.x86_64 when I try yum install package and if there were no
> problems with shared files between 32/64bit packages, all would be
> well.

Well, while some bugs could be fixed like the nuking of %doc and %lang
(although it is agrued that the multilib design in rpm is so awkward
that this requires major rewrite work in rpm which is why it isn't
beeing done), others like the punchhole bug cannot w/o removing the
multilib support in rpm. Which is why I summarized this as "multilib
needs to die, multiarch rulez".

> > > > > and we have Gentoo or Debian's pure64 solution. It's not a better solution,
> > > > > it's a different solution. Heck, it solves a different problem!
> > > > 
> > > > How is it different? They want to run i386 on x86_64 and have a clean
> > > > separation.
> > > 
> > > But we never allowed that! Except for broken packages which keep binaries
> > > outside /bin directories. That's a major change of functionality, hence
> > > my saying that's a different problem.
> > 
> > OK, I understand. Still that's probably what we want at the end.
> 
> You see, that's what I'm not convinced of. So far only two people expressed
> support for this: Ed and you. I think that's something the FESCo should vote
> on.

Sure, fesco will have to vote on this, this is just a proposal to
discuss and see what benefits/drwabacks it carries either evolving to
something that will be used or maybe hitting a blocker and be dropped.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070430/5d4e8541/attachment.sig>