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

[Axel Thimm]

On Thu, Apr 26, 2007 at 10:58:41PM -0400, Bill Nottingham wrote:
> Michael E Brown (Michael_E_Brown at dell.com) said: 
> > The biggest issue I see with any bin64 issue is that you have a *huge*
> > installed base of legacy software (and legacy software developers) who
> > just assume that you can set a clean PATH to /usr/bin:/bin, and possibly
> > /usr/sbin:/sbin. Lots of security-conscious software will do things like
> > reset the PATH.
> > 
> > Now all of a sudden, that no longer works. You have to either trust that
> > PATH isnt set maliciously, or you have to know the arch you are on and
> > that arch's specific peculariarities: prefer bin32 or bin64? etc.
> > 
> > This sounds like a lot of pain and agony for lots of people and
> > third-party software.
> 
> Moreover, you move which binary you want to prefer from a packaging
> and installer issue to a global path ordering issue and the creation
> of wrappers.
> 
> It's just dumb.

No, it's just great and KISS.

All the pain in multilib is there because it was designed to be
managed by the package manager and not really works w/o it.

Do you consider the multilib mess in rpm, both design wise
(remove/install hole punching) and the 1001 multilib bugs from
doubling most configs with rpmnew siblings to killing %doc and %lang
to silently mute all conflicts to be non-dumb?

As alternatives you have

o Reduce the use cases of multilib (e.g. like at < FC5 time, only
  support selected cases of runtime, only pollute the repo with pure
  lib legacy arch packages, or at least try to)
  => nice and clean minimal solution, but since it was abandoned, it
     seems like someone thought people need more
o Rewrite almost all specfiles to sub-subpackage *-bin and manage the
  conflicting bin suppackages
  => Overly compley with lots of implications, see my mail to David
o Rewrite multilib support in rpm, and while there rewrite rpm, still
  you'll always have the punched holes syndrome.
  => Waiting for Godot
o bin64
  => FHS persuasion powers, fix cron
o Live with the current situation
  => pain

Personally I prefer the first one, but from the rest bin64 is the least
dumb one.

Or make another suggestion.
-- 
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/33d9fa16/attachment.sig>