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

[David Woodhouse]

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

Not on my planet.

devserv /mnt/redhat/rel-eng/f7-test4-20070423.0/6.93/Fedora/ppc/os/Fedora $ ls *.ppc.rpm | wc -l
   1286

But still, you're arguing over a pointless detail. I already _accepted_
your revised estimate of 14%, which was far closer to my original
estimate of 10-20% than it was to your previous nonsense of "almost all
specfiles".

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

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

If they are arch-specific then they are broken in Fedora 7 as shipped,
and will remain broken even with your proposed model, as I said above
(actually you'd conveniently elided it, but I put it back).

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

Again, not in my world.

devserv /mnt/redhat/rel-eng/f7-test4-20070423.0/6.93/Fedora/ppc/os/Fedora $ ls *.fc6.ppc.rpm | wc -l
     49

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

Correct. It's not a problem.

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

Yep, that's expected. Don't Do That Then™.

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

The repo is healthy; the user asked for something bogus.

If I try to install glibc.ppc64 on my 32-bit laptop I get a failure too.
Is that not "healthy" either?

> > > 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.
> 
> Good, but bin64 has solved the two above, so it's a better solution.

Ok, so you're claiming that you _do_ solve the first issue just by
setting $PATH? And that nobody will ever be using /bin/$FOO in their
scripts &c, so that'll always work?

And that'll work for stuff which tries to use dlopen() of stuff
in /usr/lib (or is it /usr/lib32?) too? And which runs its own helper
binaries from /usr/libexec without looking at $PATH?

If you want to make that work, it's going to take a whole lot more work
than just splitting a few packages into libraries vs. binaries.

And then you're claiming that your solution also fixes the nebulous
'firefox issue' which you then failed to actually identify when asked
for details?

*plonk*

> Yes, fix the issues one by one instead one and for all. 

Alternatively, we can _fix_ the issues rather than trying to paper over
them and introducing new problems.

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

This is solved with our existing setup, by just installing the 32-bit
mplayer and not the 64-bit one.

> So, it global-solving all in one, or micro-solving one by one.

Your 'solution' has its own issues, and you're still massively
overestimating the amount of work it would take to split the packaging,
while conveniently ignoring the amount of work it would take to
make /bin32 work. Why don't you come back when the LSB has seen the
light and accepted your proposal and when upstream software isn't all
going to break?

Now we've talked you down from your totally bogus "almost all specfiles"
to a more sensible 14% or so, we might observe that if I'd just got on
with it instead of wasting my time on you, I'd probably have done a
quarter of the Core packages by now. And if you'd been doing it too
instead of masturbating over the precise numbers and misquoting the rest
of the discussion, we might even be half-way there.

Even if your alternative _wasn't_ going to take any work, I'm just not
interested in cutting corners because the alternative takes too much
short-term work. That's the mistake we've made with our multilib support
all along, and it's time to stop.

-- 
dwmw2