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

[Axel Thimm]

On Fri, Apr 27, 2007 at 11:59:57AM +0100, David Woodhouse wrote:
> On Fri, 2007-04-27 at 10:32 +0200, Christian Iseli wrote:
> > Why almost all packages containing bins?
> > 
> > If we have:
> >  - package A contains *both* libs and bins
> >  - package B uses libs from package A
> >  - it makes some sense to have 32-bit and 64-bit versions of package B
> >    installed in different situations
> > *then* it makes some sense (to me) to rewrite package A's spec to split
> > out the lib part.
> > 
> > But I'm hardly convinced that represents "almost all specfiles".
> 
> You're right; there is perhaps _some_ logic in allowing packages to
> contain both libraries and executables _if_ that package isn't expected
> to be installed for both architectures simultaneously. We wouldn't need
> to change the whole package set in one fell swoop.
> 
> OTOH if we make it a blanket rule, it's a lot easier to check for it
> automatically and thus to fix the occurrences. There are arguments boths
> ways.
> 
> Let's take a look...
> 
> In the early spin of F7t4 I happen to have lying around, 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?

> Of those, 516 have binaries (rpm -qlp $a | grep /bin/)

Conveniently missing the sbins.

> while 343 have libraries (grep '/lib/[^/]*.so\..*'). Note that I've
> limited it to libraries in /usr/lib -- so packages like evolution
> which provide their _own_ libraries in /usr/lib/somepackage/*.so,
> for example, don't count.¹

Conveniently missing the *-devel packages.

> The union of those lists is 126 binary packages

Sounds more like an intersection to me.

> -- less than 10% of the packages in the distribution which even need
> to be glanced at. Of those, almost all will be trivial to split. And
> some may well be false positives because they might only have
> _scripts_ in the binary dir, might have non-conflicting binaries
> (like /usr/bin/pango-querymodules-32 etc.) or on inspection we might
> conclude that the libraries would _only_ ever be required by the
> binary in the same package, so there's no need to ever have the
> libraries installed for both architectures at once.

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 I include _all_ libraries ('/lib/.*\.so.*') instead of only
> those on the search path, there are 792 packages with libraries, and
> the union of those with binaries is 245. There'll be a metric
> shitload of false positives in there, of course, but it puts the
> _upper_ bound at 20% of the packages even if we _want_ to
> overestimate it (as Axel seems to).

How can I be overestimating, or estimating at all, if I never quoted
any numbers?

The reality is that you're playing it down, even when trying to back
it up with numbers that leak false negatives here and there.

A simple stats w/o all assumptions and sbin/devel filtering out gives

(For clarification of stats: packages are binary not source)
8385 total packages in F7/i386
6569 i386 packages in F7/i386 (78%)
2862 i386 packages with binaries in F7/i386 (34%)
3096 i386 packages with libraries (under /usr/lib directly) in F7/i386 (37%)
1135 i386 with binaries and libs in F7/i386 (14%)

So the true number is 14% amounting to 1135 packages, which *could*
[1] amount to 606 specfiles, which amounts to 40% of today's rawhide
FC. What is the rate of completed merge reviews? That could give you
an idea of how many resources "fixing" these 606 package will need.

So, if I have to give an estimate for a lower bound, it is 14% and 606
specfiles. And that's only for limiting to splitting off sub-sub-bins
in presence of libs.

And you still remain with the problem of conflicting packages, and
haven't solved even the pkgconfig issue or firefox like issues (or any
other category-similar issues), so basically all you did is avoid the
punchole bug (which is good, of course), but at a high cost w/o much
further side effects. Special handling is still needed at all other
places.

And now compare again to the bin64 case: Still far less work and
higher gains, as it allows virtually any scenario, including using
non-patched i386 pkgconfig/firefox etc. bits directly. You cover all
target groups, those that you can think of today, and that that may
come up tomorrow.

[1] I'm just linearily scaling 4474 src.rpm -> 8385 creates
    binary/noarch packages. A more thorow analysis would be quoting
    src.rpms and not noarch/i386 numbers.
-- 
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/34b336e1/attachment.sig>