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

Axel Thimm Axel.Thimm at ATrpms.net
Thu Apr 26 09:21:01 UTC 2007


On Thu, Apr 26, 2007 at 09:56:33AM +0100, David Woodhouse wrote:
> On Thu, 2007-04-26 at 10:24 +0200, Axel Thimm wrote:
> > On Wed, Apr 25, 2007 at 10:03:00PM +0100, David Woodhouse wrote:
> > > > > > [... Changing all specfiles by splitting out bin subpackages
> > > > > > vs simply defining a new _bindir ...]
> > > > > Yes, but it does involve much more work to do.
> > > 
> > > Packaging is hard. Let's go shopping.
> > 
> > No, the above is not hard to do, it is a straightforward thing to do
> > that will occupy a full or more than one release cycle(s).
> > 
> > I prefer to get F8 with some new features as well and not only a mass
> > review again. Which wil involve thre times as many packages as the FC
> > merge review which we didn't manage to finish.
> 
> Actually, this one should be quite easy to automate.
> 
> We've spent too long trying to take short-cuts and do the easiest thing
> in the _short_ term for multilib -- and it shows. It's time to start
> doing it properly, IMHBCO.

Exactly and the proper thing for multilib is: Let it die, multiarch rulez!

> I'll entertain discussion about whether banning these conflicts is
> 'proper', but with all due respect I'm not too interested in discussion
> about the fact that it might actually take a small amount of work to fix
> the packaging so that we can remove this dirty problematic filecolours
> hack from RPM.

You misunderstood me, I'm all for removing all special support in
rpm. That's why I propose to fix this at a lower level than rpm, so
rpm has nothing to solve anymore.

> Packaging is hard. Let's go sailing.

No, you're full of free time activities, how about

Packaging is fun, let's go package new stuff, and not repackage old
for the umpteenth time?

> > > RPM shouldn't be making those decisions.
> > 
> > Indeed.
> >
> > > It should just be installing what it's told to, and it shouldn't be
> > > told to install stuff which conflicts.
> > 
> > Agreed. But in your proposal of splitting out all bin parts, the bin
> > parts would still conflict, so no /usr/bin/firefox and no
> > /usr/bin64/firefox.
> 
> That's true (well, actually not for firefox right now but we plan to fix
> that and eliminate the shell script in /usr/bin). But that's because
> we've never really had 'coinstall _binaries_ of both architectures' as a
> goal of our multilib support. It's multilib, not multibin. 

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.

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.

It sounds like more changes/work than it actually is.

> Multilib is about coinstalling libraries for both runtime and
> development purposes -- but not binaries. That's a new requirement,
> and not something we've ever tried before.

It's not really a requirement, but yet another nice side-effect.

> I don't think we can manage it within the scope of the LSB. However, we
> _can_ let the user choose which binary is installed in /usr/bin. And
> perhaps we can let them install the other one with --relocate?

Ouch, no, please, no relocate, 99% of open source software projects
don't support this. This is mainly a mechanism for ISVs that do make
their software relocatable as their ship it in closed source and the
user need to be able to move it around in /opt or whereever he need
it.

> Do we really want to let them install both?

If they want to. It shouldn't be the default, though.

Just ask who the target users of multilib (or multiarch) are. For
quite some time we assumed only users that wanted to have runtime
support for a couple not ported parts. Later we discovered that
developers want to use this platform (w/o chroots) and started the
*-devel hacks. So it is natural to assume that these developers and
user may even want to run their bits in a packaged form and not just
under /ustr/local.

The bin64 proposal has many merits, the main drawback is FHS/LSB, but
these institutions are not our enemies, part of doing this step would
be to involve them, explain the motivations and ask for supporting the
new model as well (which isn't new, but anyway).

We are already violating the FHS due to multilib (libexec) and it is
difficult to even explain the implication to non-multilibers that lead
to libexec != libdir/%{name}. Going multiarch would allow us to drop
libexec, so we'd be just replacing one violation with another
currently.
-- 
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/2131446a/attachment.sig>


More information about the Fedora-maintainers mailing list