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

[Dominik 'Rathann' Mierzejewski]

On Friday, 27 April 2007 at 02:26, Axel Thimm wrote:
> On Thu, Apr 26, 2007 at 10:39:23PM +0100, David Woodhouse wrote:
> > On Thu, 2007-04-26 at 21:30 +0200, Axel Thimm wrote:
[...]
> > > The "David Woodhouse improved multilib design that requires bin
> > > suppackage splits for every bin carrying package" tries to circumvent
> > > this problem by spliting out the bin contents in subpackages. But this
> > > is another bad short-term decision, as it
> > > 
> > > o forces us to revisit every bin carrying package out there speding
> > >   tons of resources better used elsewhere
> > 
> > You overestimate the effort involved. It can be checked automatically,
> > and when conflicts are found, the fix is simple.
> 
> Ok, a hands on example to demonstrate that this is not so:
> 
> %build
> blah
> 
> %install
> blub
> 
> %files
> %{_bindir}/foo
> %{_datadir}/foo
> 
> %files mon
> %{_sbindir}/foo-mon
> %{_localstatdir}/lib/foo-mon
> 
> %files devel
> %{_bindir}/foo-config
> %{_includedir}
> 
> So you want to sub-subpackage all three subpackages to a total of 6
> subpackages with interesting set of intra-dependencies and you even
> claim that this will happen automatically w/o a human going through
> the specfiles? So let perl and sed automatically mungle the specfiles?
> Or what other automatic management would you apply? If a package
> required foo, does it now require foo-bin or foo ("the rest")? You
> can't know w/o reviewing this. Does foo-bin require foo ("the rest")
> or foo ("the rest") require foo-bin? You will find out that both is
> needed, so you will have tons of circular dependencies.

No. This package is not multilib-able. Period. It's either one arch,
or another. It has no files in %{_libdir}.

[...]
> > > In comparison the bin64 solution costs us almost nothing:
> > > o most packages will rebuild in unattended mode
> > > o breakage of false bindir will be detected during the build itself
> > > o You can use two cleanly distinct repos with the depsolver tools of
> > >   today, no need to add any funny support anywhere
> > > o You fix an FHS violation, in exchange for another, which just brings
> > >   us bad to balance
> > > o The FHS has already considered this (thanks to the Debain folks) and
> > >   is waiting for distros to actually utter the demand to include it.
> > 
> > It buys you the ability to install _both_ versions of the package
> > simultaneously, but you can't easily choose which version to prefer for
> > a _specific_ package -- you can only set bin64 before or after bin in
> > $PATH, which affects _all_ installed programs.
> 
> Always before. If you install both the default invocation makes bin64
> win. The other arch is the legacy arch (at least for i386/x86_64), so
> it shouldn't default itself to higher priority.

Why always? ppc and sparc prefer 32bit binaries because of serious
speed difference.

[...]
> > Unless you split the packages out so that you can have libraries
> > installed for the secondary arch without having to have the
> > binaries, I suppose? :)
> 
> That does not make sense at all. Because now you can't choose at all
> at runtime, you need to uninstall and install the other version,
> that's hardly a better way than to simply call a prefix to the
> command, just compare:
> 
> bin64:
> 
> yum install firefox.i386 firefox.x86_64
> firefox -> 64 bit firefox, damn that flash website doesn't work
> goi386 firefox -> 32 bit firefox, view that ugly flash site
> firefox -> back to sane 64 bits
> 
> Dave's multilib2:
> 
> yum install firefox-bin.x86_64 firefox-libs.x86_64 firefox-libs.i386
> firefox -> 64 bit firefox, damn that flash website doesn't work
> yum remove firefox-bin (wait)
> yum install firefox-bin.i386 (wait more, needs to be always online or
> 			     have big yum cache)
> firefox -> 32 bit firefox, view that ugly flash site
> yum remove firefox-bin (wait)
> yum install firefox-bin.x86_64 (wait more, needs to be always online or
>                                have big yum cache)

You're talking multiarch again. We don't want to have both 32bit
and 64bit binaries installed! I know diskspace is cheap, but the user
doesn't need two binaries for each application.

You install either 32bit or 64bit version and use that. Why switch
at all?

Regards,
R.

-- 
Fedora Extras contributor  http://fedoraproject.org/wiki/DominikMierzejewski
Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"