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

[Axel Thimm]

On Fri, Apr 27, 2007 at 02:20:19PM +0100, David Woodhouse wrote:
> On Fri, 2007-04-27 at 14:13 +0200, Axel Thimm wrote:
> > > there are 1286 32-bit binary packages.

> > In today's rawhide of the upcoming merged F7 there are 6569, you
> > already cut away 80% of the packages. You are not implying that we
> > only fix 20% of the packages because they happen to be on the CD?
> > 
> > Or that we constrain our analysis on only was has been cherry-picked
> > for a spin and is know to be working multilib wise?
> 
> No, this is _all_ the ppc32 packages in the ppc compose.
> Although of course you're right that it doesn't include Extras.

Hardly even Core. ppc for Core has 3076 32-bit packages, not 1286.

> > Conveniently missing the *-devel packages.
> 
> By omitting /usr/lib/*.so, you mean? OK, we can add that too if you want
> to nitpick '^(/usr|)/lib/[^/]*.so(|\..*)$'). Then we need to remove a
> bunch of false positives with just stuff like /usr/bin/pcre-config which
> is a script not an executable, and we gain 21 more source packages, for
> a total of 160 -- or 12%.

No, these are not false positives:

# grep -l lib64 /usr/bin/*-config | wc -l; ls /usr/bin/*-config | wc -l
43
89

This is on a typical FC6/x86_64 install maxed by click all in, not
@everything, so it is a sample, but it indicates that half the
*-config packages *are* architecture specific.

> > OTOH you are missing all foo-config scripts that are in foo-devel and
> > are arch specific, this outweights any false positives like the ones
> > you describe.
> 
> If those are arch-specific then they're broken,

Well, anything that does not suit your model is tagged as broken and
needs fixing. Maybe it is, maybe not, but the bin64 model does not
care, it can live with both, w/o having us to fix all and everything
before we can thinkn about multilib.

> We can keep refining it all day, but I don't really see the point unless
> we're actually going to start filing bugs against the ones which need
> splitting.

But there is no point in filling bugs against healthy packages. Just
to follow your proposed model of conflicting sub-sub-packages?

> So a more interesting statistic might be the number of binary packages
> which weren't rebuilt between FC6 and FC7 -- which is about 47 judging
> by the disttags.

Well, since I did the math recently, I can tell you that this number
is *very* bogus. Otherwise there wouldn't had been any dicussion at
all about mass rebuilds.

> > And you still remain with the problem of conflicting packages, 
> 
> There is no _problem_ with conflicting packages. There are only
> conflicting packages, which you may not install simultaneously.

Aha, and that's not a problem, huh?

yum install foo.x86_64 foo.i386
[...]
File boo from foo.x86_64 conflicts with file boo from foo.i386
[...]

yum/smart/apt assume a *healthy* repo. Not one that will have
transaction failures planned in.

> > haven't solved even the pkgconfig issue or firefox like issues (or
> > any other category-similar issues),
> 
> Neither have I solved world hunger.

Good, but bin64 has solved the two above, so it's a better solution.

> These are unrelated issues which as far as I can tell your solution
> doesn't solve either.

World hunger? Giving the savings in resources perhaps every devlopers
will donate a penny for each saved hour and we'll solve that, too.

> If you have to have your $PATH set to /bin64 or /bin according to
> whether you're building for 64-bit or 32-bit, to make sure you pick
> up the right foo-config or pkgconfig .pc files, then that's still
> broken.

Why, the developers just hits "goi386" and voila this xterm turned
into a pure i386 xterm, where he can work just like on a pure i386
system. That's not broken, that's just great.

> And I'm not sure _what_ you're referring to w.r.t firefox. Once we have
> xulrunner (which can be installed for both arches simultaneously) and
> separate firefox (which can not), that all works just fine. You install
> plugins for one arch or the other, or both. There's no problem here.

Yes, fix the issues one by one instead one and for all. You can also
fix the pkgconfig issues, and libtool and whatnot, until the next one
comes around the corner. That's why I wrote "category-similar issues",
there will always be a "firefox" that you will need to run on i386,
and "pkgconfig" build tools that will resist to be multilib'd.

mplayer on certain codecs come to mind, which would also benefit from
allowing both of them to install. mplayer foo fails? Then just try
/usr/bin/mplayer foo? It just works w/o packaging mplayer-32 on
x86_64? Great.

So, it global-solving all in one, or micro-solving one by one.
-- 
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/20070427/53b23160/attachment.sig>