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

Re: Time to make Extras multi-lib?



On Thu, 2006-06-22 at 13:05 -0400, Jeremy Katz wrote:
> On Thu, 2006-06-22 at 11:54 -0500, Callum Lerwick wrote:
> > On Thu, 2006-06-22 at 14:21 +0200, Axel Thimm wrote:
> > > o Minimal ("application POV"): only what doesn't natively run:
> > > 
> > >   This algorithm should start with a simple manual decision of what
> > >   top-level packages to pull to 64 bits at all (including such not
> > >   existing in Fedora space, e.g. ISV products), and then pull in all
> > >   run-time dependencies, too.
> > > 
> > > o Full compat bloat ("lib POV"): In addition to the above approach,
> > >   one would blindly copy every lib containing package over.
> > 
> > Yeah I'm somewhat confused as to what the goal is. In the case of
> > x86_64, IMHO multilib exists only for legacy compatability, (Mostly, for
> > running Wine, and maybe flash...) and in the long run, 32bit needs to
> > die die die. Thus the minimal approach makes sense here.
> 
> Except that people want to be able to continue to run older apps.  The
> 32-bit compatibility is the primary thing that makes migration to x86_64
> far easier than another arch (such as ppc or ia64).  While originally I
> was a proponent of the minimal approach, a few years of experience have
> me changing my mind about what's desired

+1. Making all possible i386 bits available in the x86_64 tree does
nothing to hurt folks who want pure x86_64 -- they simply don't install
any of the i386 bits (or only the bits they want). At the same time, it
makes life much easier for those who need i386 libxyz for whatever
reason, be that some app that is still only 32-bit, for 32-bit
development, or what have you (remember, a fairly significant part of
the user base is still 32-bit).

Neither the folks who want pure 64-bit or the folks who want the
full-b(l)oat lose here. The minimal approach suits the people who want
pure 64-bit more, but leaves the other (loose) grouping of people out in
the cold, having to manually suck bits from the i386 tree.

-- 
Jarod Wilson
jwilson redhat com

Attachment: signature.asc
Description: This is a digitally signed message part


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