On Mon, Apr 30, 2007 at 03:24:12PM +0200, Phil Knirsch wrote:
> 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. 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".
> >
>
> One thing you have to be very careful about multiarch is that you don't
> fall for the easy solution.
>
> Just adding [loadsofprefixes]/bin64 will not fix world hunger,
> especially when you then suddenly in the years to come get a CPU that
> might support 32bit and 2 64bit archs. Then you're then screwed all over
> again, just like with the "No application will ever need more than 640kb."
You can refine this solution to not plain dump bin64 folders, but full
triple-platform defining folders. In fact I think the original Debian
multiarch suggestion went as far as to define it that way. The idea
was not only to support 2,3,4 subarchs on a single system, but even
sharing the same tree among their 11 something supported archs over
NFS. Well, I wouldn't ever mount a "global NFS root".
The point is that once you have undone any /usr/bin hardcoded paths in
packages you can easily move them to any possible new layout.
> The solution debian and Gentoo iirc use which are basically buildroots
> is the only way i know how you can cleanly separate various archs on one
> system. Sadly you'll then loose the common and sharable files, but any
> other solution will need very carefull and detailed planing.
Personally I prefer banning multilib in rpm for good and if that would
be best done by using chroot solutions, I'm all for it. The multilib
implementation within rpm magic just isn't scaling and produces more
bugs on the way than we can fix.
> (You could ofc ahackishly lways just run hardlink on / after each
> package installation ;) ).
>
> Read ya, Phil
>
--
Axel.Thimm at ATrpms.net
Attachment:
pgpyQRoQC9FLj.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
