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

[Axel Thimm]

On Tue, May 01, 2007 at 02:52:39PM +0100, David Woodhouse wrote:
> I'm not going to bother contradicting you where I've already done so and
> you're just ignoring what's gone before...

Nice way of eliding the fact that your proposal nukes config files,
just to name one established fact, that you generously look over.

> On Tue, 2007-05-01 at 11:32 +0200, Axel Thimm wrote:
> > o thus borks yum, anaconda, smart and apt
> 
> ... except for this one. Just in _case_ there's anyone left who actually
> takes your nonsense seriously....

Nice, you still keep up that adolescent behaviour.

Just ask your local rpm/yum representative: Packages with file level
conflicts are hell and were the reason the FPC had to make a guideline
out of it.

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.

> 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. yum is also not a
tool for trivial one-package installs, the complexity comes with
dependencies, conflicts and multiple package operations. Also whatever
conflicts and inter-packages brokenness doesn't show up if you install
a single package on a non-conflicting setup. But you probably know
that, so do we.

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?
...
-- 
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/b9756fbb/attachment.sig>