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

[Axel Thimm]

On Wed, Apr 25, 2007 at 07:16:20AM -0400, Jakub Jelinek wrote:
> On Wed, Apr 25, 2007 at 10:52:40AM +0200, Axel Thimm wrote:
> > The default setup is to use x86_64 bits. Pruning the (s)bin64 parts
> > out of the path you get a pure i386 system (with annoying lib64
> > folders, see below).
> 
> {,s}bin64 is a terribly bad idea.  For almost all binaries (very few
> exceptions) users don't really care whether they are running 64-bit
> or 32-bit binary, it should have exactly the same functionality.

You could argue that the only reason multilib exists at all is that
one arch has some benefits over the other, like the one having a
better performance of the hardware resources, but the other carrying
more packages (especially from ISVs these days). This is the typical
i386/x86_64 dilemma.

> So having both /bin/ls and /bin64/ls serves no useful purpose

Consider (*)

yum install foo.i386
yum install foo.x86_64
yum remove foo.x86_64
rpm -V foo
(same for smart and apt)

The current multilib model in rpm with blindly overwriting files is
broken by design (e.g. unfixable in shared bindir environments). You
cannot consider the packaging system a stateless machine anymore.

Adding to the design issues there are also implementation bugs with
%docs and %langs that get uninstalled when the i386 package gets
uninstalled and so on. Furthermore foo.i386 and foo.x86_64 packages
often alread conflict on other files which is silently muted during
coinstallation.

It is getting so much convoluted with rpm, yum and anaconda exceptions
and bug workarounds that we need a clean model. And packaging wise
this means no more overwriting of files with foreign contents.

> (in addition to violating FHS).

Yes, that's severe, but due to multilib we were forced to break the
FHS (libexec) anyway, and currently the FHS is adjourning again and we
could bring that in. I already submitted a request to consider adding
libexec to the next FHS, but if we were to go bin64, we don't even
need it anymore and I could instead promote for bin64.

> I believe there is no reason to kill rpm's multilib handling, as
> long as it is configurable which arch is preferred

Well, if all rpm multilib bugs are fixed, whereas fixing (*) above is
impossible, that could sound OK, but we have these bugs in rpm for
years, from the very first day of multilib in rpm, and nothing is
happening. This is not an offence against Paul & friends, who're doing
their best at fighting the rpm monster, it is just that rpm's code is
still that unmaintainable and perhaps we need to lift off some
mechanisms to lower end mechanics.

Like for example solving the multilib issue w/o the aid of the
packaging system, so that the packaging system gets back to where it
belonged, maintaining single packages and their dependencies.

> If we through some tag annotate all packages ("this package should be
> only installed for the primary arch", "this package can be installed for
> both arches if needed (usually library package)", "this package should
> only be installed for one arch, preferrably XYZ"), then yum etc. can
> make smart decisions fairly cheaply and we can also use the separate
> arch repositories easily.

You're advocating the opposite, e.g. let higher level tools solve the
issue. But if the lower levels fail (like install/remove a package not
being a zero-op, or buggy behaviour nuking %doc/%lang), then yum and
anaconda will fail, too.

Therefore we should really examine the solutions at the low end scale
and bin64 would be such a solution that is functionally at least
equivalent to the current situation while "fixing" in one sweep all
rpm multilib bugs (by not having to use any rpm-multilib features).
-- 
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/20070425/49e3be77/attachment.sig>