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, Apr 26, 2007 at 03:12:17PM +0200, Ralf Corsepius wrote:
> On Thu, 2007-04-26 at 13:50 +0200, Axel Thimm wrote:
> > On Thu, Apr 26, 2007 at 11:27:00AM +0200, Ralf Corsepius wrote:
> > > On Thu, 2007-04-26 at 11:21 +0200, Axel Thimm wrote:
> > > > 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!
> > > 
> > > Apparently you haven't understood what multilibs are.
> > 
> > Obviously your personal definition of multilib includes
> > cross-compiling for x86_64 on i386.
> Yes, because THIS is multilib'ing.
> 
> >  But we call multilib something else here, please adjust.
> 
> The concept of multilibs as being defined by GCC exists for than a
> decade (More precisely: <= 1995). 
> 
> What you are naming multilibs is mixing architectures at run-time.
> The correct term for this would be multi-arch'ing or bi-arch'ing as far
> as the ix86 family is concerned.
> 
> Multilibs can be applied to implement multi-arch'ing, but actually
> multi-arching isn't tied to multilibs at all.

OK, so we agree, we have a different definition of multilib than you
do. since all on this list use multilib in the "mixing arch" version
of the definition, please adjust, otherwise you only confuse us. :)

I'm sure both you and we understand both uses of multilib. And even if
you don't agree to our usage maybe you can comment more on the
technical parts than whether the given name is appropriate or not.
-- 
Axel.Thimm at ATrpms.net

Attachment: pgpsvj8g0nDGv.pgp
Description: PGP signature

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