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

Fri Apr 27 17:32:15 UTC 2007

On Fri, Apr 27, 2007 at 05:35:03PM +0100, David Woodhouse wrote:
> 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.

Earth to planet David, earth to planet David!

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

# cd /storage/public/mirror/download.fedora.redhat.com/pub/fedora/linux/core/development/ppc/os/Fedora; ls *.ppc.rpm | wc -l
3076

Are you really only after fixing the bits that are on CD? I'd like to
stay a bit more global and do Core and Extras.

> But still, you're arguing over a pointless detail.

No, don't subvert statistics, your numbers are always based on your
ppc compose. That's not the complete set of Fedora packages affected
and not only it "doesn't include Extras", but "hardly even Core".

So that's how at the end you get at 47 packages that need to be fixed
instead of 606.

Pointless detail? Well, whatever.

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

No, that's just not the case. /usr/bin64/foo-config gives me info for
how the package is built under x86_64, /usr/bin/foo-config for i386.

Not only could the paths diverge, but even parts like -DMMX may be
different.

Yep, separating foo-configs is the long term solution.

So, no convenient elusion, but just a plain fact that shouldn't need
more commenting (but obviously it did).

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

In our world this number is more like 759.

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

It is expected to have a broken repo? yum defines this as a broken
repo, the packaging guidelines define this a broken behaviour (for
good reasons, there should not be file level conflicts, but package
level conflicts, and no, rpm does not support cross-arch conflicts) 

So, what you prosose is a messier situation than the current multilib
one. No, thanks.

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

Sure, the error is always in front of the keyboard. Convenient
long-term solution.

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

I did write that simply setting _bindir will not be enough, but it
will cover most packages.

> And that'll work for stuff which tries to use dlopen() of stuff
> in /usr/lib (or is it /usr/lib32?) too?

That does not change from today's lib/lib64 split.

> And which runs its own helper binaries from /usr/libexec without
> looking at $PATH?

You missed the part about libexec, which BTW is another reason for
going bin64. We can finally move libexec to libdir as the FHS mandates
(while violating the FHS again, so FHS-wise it is a
stalemate).

libexec today is used as bindir, which means file munging and
punchholes.

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

Are you reading or just ranting? Of course I answered on the firefox bits.

> *plonk*

Get out of the bin, please.

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

I agree, so why do you suggest to have bin sub-subpackages that will
be file-conflicting?

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

# yum install mplayer.i386
file /usr/bin/mplayer from mplayer.i386 conflicts with file /usr/bin/mplayer from installed mplayer.x86_64
<rant>
# yum remove mplayer
mplayer is needed by ...
<rant, rant, rant>
# rpm -e --nodeps mplayer
# yum install mplayer.i386
<wait, wait, wait>
# mplayer foo
<hm, mplayer.i386 cannot play it either, or I just want my x86_64 version back>
# yum install mplayer.x86_64
file /usr/bin/mplayer from mplayer.x86_64 conflicts with file /usr/bin/mplayer from installed mplayer.i386
<argh, slamming keyboard against the display>
# rpm -e --nodeps mplayer.x86_64; yum install mplayer
Sorry, you are offline, please try later
<throwing the laptop off the plane>

The better solution:

# yum install mplayer.i386
# goi386 mplayer foo
<hm, mplayer.i386 cannot play it either, or I just want my x86_64 version back>
# mplayer foo
<OK, that was smooth, now I have time for solving the world hunger problem>

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

Well, our estimates are a factor of 15 (e.g. 759/49) apart, since on
your planet there is only the ppc compose, but you're ignoring the
rest of Core and all of Extras.

But I do think the the Fedora project will not drop half of Core and
Extras to accomodate your planet.

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

The LSB, or better said the FHS are ready to give green light the
moment some distro seriously inquires, check the ongoing multiarch
discussions there.

> Now we've talked you down from your totally bogus "almost all specfiles"
> to a more sensible 14% or so,

OK, so I was a factor 7 wrong, while you are a factor 15 apart?

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

Cool, please finish all by tomorrow, so we can see yum break. I'm sure
the yum developers will be glad for that.

> And if you'd been doing it too instead of masturbating

Sorry, other than foobaring the numbers to your convenience you used
vulgar talk, that has no place on this list, back to the bin!

*PLONK*
-- 
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/552177c3/attachment.sig>