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.
Of those, 516 have binaries (rpm -qlp $a | grep /bin/) 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.¹
The union of those lists is 126 binary packages -- 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.
--
dwmw2
¹ 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).
--
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
