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

[Axel Thimm]

On Thu, Apr 26, 2007 at 06:21:40AM -0400, Jakub Jelinek wrote:
> On Wed, Apr 25, 2007 at 06:52:21PM +0200, Axel Thimm wrote:
> > > 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.
> 
> That's all solvable in the package management or by packaging decisions

Not really, as you later explain, you would have to recreate the
punched out files in the current model.

> (basically split current packages into subpackages based on the current
> %_filecolor - color 0 (aka binaries and data files) would generally stay
> in the packages, color != 0 (primarily libraries) would go into new
> subpackages (*-lib or *-libs or something).  I believe this is what
> dwmw2 is envisioning.  Even with current %_filecolor the above is solvable,
> if you have both foo-1.2.3-6.i386 and foo-1.2.3-6.x86_64 installed and
> they have color 0 files with different content between the arches,
> to remove foo-1.2.3-6.x86_64 and keep foo-1.2.3-6.i386 all you really need
> is to be able to recreate those 32-bit files.

Exactly, and if we would have to add this to rpm, too, then God beware
of the breakage in rpm.

> You are proposing */{,s}bin64 basically as a filesystem cache for
> such a rare operation.

Not only, consider the above being firefox or somethign where it
really matters whether you use i386 or x86_64. The user *wants* to run
the i386 bins.

> On the filesystem people really want multilib, not multibin or
> multiarch you are proposing.  It works in multiple OSes and has been
> in use for years (Irix, Solaris, Linux).

I doubt people even really want multilib, you have two kind of people:

o users that don't care at all about i386 and if they weren't forced
  to they wouldn't have a single i386 package on their x86_64 system.

o developers/testers that "abuse" x86_64 arch for developing and testing
  i386 software on the same hardware.

Up to the previous release we were focused on the first group only,
and if we had continued we would had *decreased* (!) the numer of
multilib packages, since some important ones finally made it to native
x86_64.

Instead we decided to support the second group as well introducing
heuristics for "multilib development", which in reality should be
transcriped as "too lazy to use a real i386 environment and be that in
a chroot".

Well, for whatever reason, we support that model, and then developers
and testers need a place to actually install their bits. We're looking
away since they usually install under /usr/local/bin and happiliy
overwrite their 64/32 bit mixed up bindir folder.

But the more we support this model the uglier it gets: It is far more
easier to ship two pkgconfigs, one in /usr/bin and one in /usr/bin64
that return appropriate infos for the subarchs, than to make pkgconfig
multilib aware. Same for a gazillion other similar to-be-multilibed
tools. And the recent perl.so crazyness.

We just get deeper and deeper into multilib's inadequate frameworks
for what we are targetting.

Therefore we either

o need to revisit the goals, e.g. realize that the multilib design was
  at best for the users that need runtime support, and then live with
  the bugs as up to FC5, or

o admit to a larger target group, where users mix and match as they
  please for developing i386 under x86_64 w/o chroots and create a solid
  architecture which doesn't rely on packages punching holes into other
  packages.

Currently we're targeting the latter user group with the former tools,
that's what's creating the pain.
-- 
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/20070426/fa41bd17/attachment.sig>