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."
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.
(You could ofc ahackishly lways just run hardlink on / after each
package installation ;) ).
Read ya, Phil
--
Philipp Knirsch | Tel.: +49-711-96437-470
Development | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <phil@xxxxxxxxx>
Hauptstaetterstr. 58 | Web: http://www.redhat.de/
D-70178 Stuttgart
Motd: You're only jealous cos the little penguins are talking to me.
--
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
