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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

Packaging is hard. Let's go sailing.

> > 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. 

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. 

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?

Do we really want to let them install both?

-- 
dwmw2

--
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

[Index of Archives]     [Fedora Users]     [Fedora Development]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux