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

[David Woodhouse]

On Fri, 2007-04-27 at 14:13 +0200, Axel Thimm wrote:
> 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.

> > Of those, 516 have binaries (rpm -qlp $a | grep /bin/)
> 
> Conveniently missing the sbins.

Good point; thanks for pointing it out -- which was of course the reason
why I included the precise method I used. So that takes the number to
613 instead of 516, and the intersection (doh, sorry) becomes 141
packages, from 139 source packages.

> > 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.

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%.

> 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, because it means you
can't currently build for both architectures correctly. And your
solution doesn't help there either, because you still pick up the first
one on $PATH instead of the _right_ one according to what you're
compiling for.

> 1135 i386 with binaries and libs in F7/i386 (14%)

I could nitpick your precise numbers but there's no point -- that figure
is within the noise margin of both my original and revised (above)
estimates, and I'd only make myself look silly.

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.

> 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.

The rate of completed reviews is totally irrelevant. Getting those done
involves getting someone _else_ to pay attention to a package they don't
necessarily care about.

Since the bins vs. libs check can be automated, the package maintainer
can do it themselves in a very short period of time -- and the need for
it can be automatically flagged by the build system.

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. So if the problem is flagged on a rebuild, then only 4%
of packages would get through to F8 without being automatically caught.
And that's assuming we don't do a mass rebuild between now and then,
which is unlikely. I think FC7 was the first time we haven't done one.

> 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.

Yeah, that seems reasonable if we're going to insist on _all_ packages
meeting the guidelines (which is required for it to be automatically
caught, of course). If we are going to limit to those packages which a
sensible user might _want_ to install for the secondary arch, then
there's a lot of them which we don't need to 'fix'. Including most of
what's currently in Extras, I would imagine. 

If we don't make it mandatory then it can easily be done piecemeal -- a
given package can be fixed only if and when someone comes up with a good
reason to have it installed in parallel and _tries_ it, and files a bug.
I suspect we'd probably fix it in advance for everything currently in
Core, and let the current Extras packages be converted as required.

> 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.

> haven't solved even the pkgconfig issue or firefox like issues (or any
> other category-similar issues), 

Neither have I solved world hunger. These are unrelated issues which as
far as I can tell your solution doesn't solve either. 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.

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.

-- 
dwmw2