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
Attachment:
pgp58KQ9sNOvi.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
