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

[Axel Thimm]

On Tue, May 01, 2007 at 09:19:40PM +0100, David Woodhouse wrote:
> On Tue, 2007-05-01 at 21:08 +0200, Axel Thimm wrote:
> > But yum maintainers, the FPC and the rest of the world don't see
> > things as clear as D.W., so we should undo guidelines and allow file
> > level conflicts for D.W.'s sake.
> 
> You seem confused -- or deliberately confusing. I'm talking about RPM
> allowing _fewer_ file conflicts than those we already allow, not more of
> them.

And you are trying to confuse by inspecting parts of your proposal out
of the whole context, and discussing about rpm when the flaws are in
your proposed packaging scheme.

You want to drop multilib support in rpm and I'm all for it, that's
not the problem you're looking away from. Have rpm allow no file
conflicts, yes, please, I'm backing you up on this (but not for bin
sub-sub-packages, but for going multiarch).

BUT! You are promoting to have bin sub-sub-packages that *WILL
CONFLICT* on a file level. So the rpm manager you just had allow
_fewer_ file conflicts will stab your new packaging methods in the
back (and rightfully so).

Not the removing of multilib support in rpm is bad, but your bin
sub-sub-packaging.

Still confused? I bet so.

> > > Yum did not break. Again, what you say is untrue.
> > 
> > yum does not break if it doesn't have to deal with both packages,
> > which may be pulled in by different dependencies.
> 
> And how might they be pulled in by different dependencies? In practice,
> not just contrived cases which we wouldn't actually see in Fedora for
> real?

Like mybrowser.x86_64 requiring java.x86_64 and yourbrowser.i386
requiring java.i386? Real enough? Just add your favourite browser
names in the templates.

> > Just try the normal user use case, where he will try to install
> > foo.i386 while foo.x86_64 is already installed. "Don't do that!" would
> > be your cure probably, and yumex will paste a backtrace onto the
> > users' screen. Wasn't multilib supposed to improve user experience?
> 
> That is currently (in FC7) not behaving optimally, and the post-F7
> multilib plan improves it by getting rid of the mess like bug #235524. 

You're comparing apples and bananas now, again. The broken use case
refers to your proposed bin sub-sub-packaging w/o any multilib support
in rpm and bug #235524 and your comment above to the actuall current
setup on rpm multilib bugs.

> When that's done, and it makes sense to _switch_ a package from x86_64
> to i386, that isn't hard to support in yum as a single transaction. RPM
> is already capable of it, of course.

Yeah, sure, you just forget about dependencies, the redownloading of
everything (or mega-caching everything that the user needs), and
nuking config files. Your proposal needs serious band-aids on every
level.
-- 
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/20070501/730e9382/attachment.sig>