[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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?


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"

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]