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

[Axel Thimm]

On Thu, Apr 26, 2007 at 10:33:48AM +0100, David Woodhouse wrote:
> On Thu, 2007-04-26 at 11:21 +0200, Axel Thimm wrote:
> > It's called multiarch, not multibin.
> > 
> > And that was the main problem with multilib and shortcut solutions:
> > multilib was the shortcut solution, and implied all the pain of the
> > last years.
> 
> Not _all_ of the pain. A lot of the pain came from making stupid
> short-term decisions, like the filecolour hack in RPM which we're
> currently referring to. There was never any need for that, except
> perhaps as a short-term hack.

Which is only needed once you start allowing (in your concept) files
of one "color" to be overwritable by another.

If you put at the top of your specs that you won't allow any
multilib/multiarch/multifoo design to allow for such dirty tricks then
you don't need that anymore.

And that's what the bindir=>bin64 proposal does.

> Multilib _really_ doesn't need to be as painful as it has been in the
> past, if we start thinking about it a little more coherently.

Agreed.

> > Ditch multilib for good, go multiarch and forget about rpm special
> > handling, punched install/remove holes (that are firmly embedded in
> > the multilib design) and all the multilib pain.
> 
> 'punched install/remove holes'? 

See a prvious mail, but for the sake of context:

yum install foo.i386
yum install foo.x86_64
yum remove foo.x86_64
rpm -V foo

Many punched holes, there is no state machine reliability in rpm by
(multilib) design. You can only get that wokring if you don't allow
foo.i386 and foo.x86_64 to contain conflicting files, e.g. move your
bins to different folders. Then (package bugs aside) you can
install/remove as you wish and the result is history-free.

> > It sounds like more changes/work than it actually is. 
> 
> I'm listening.... be specific. How does it work?

-%_bindir                %{_exec_prefix}/bin
-%_sbindir               %{_exec_prefix}/sbin
-%_libexecdir            %{_exec_prefix}/libexec
+%_bindir                %{_exec_prefix}/bin64
+%_sbindir               %{_exec_prefix}/sbin64
+%_libexecdir            %{_exec_prefix}/%{_lib}

And sure, there will be packages with hardcoded bindirs to /usr/bin,
which we'll automatically detect on the first rebuild.
-- 
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/6c4a02bf/attachment.sig>