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

[Dominik 'Rathann' Mierzejewski]

On Friday, 27 April 2007 at 18:57, Axel Thimm wrote:
> On Fri, Apr 27, 2007 at 06:42:20PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> > 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}.
> 
> Ah, "minor" forgotten detail. Just fill the blanks, with
> %{_libdir}/*.so.* and %{_libdir}/*.so.

In that case, you can have both 32bit and 64bit -libs installed (because
they don't conflict), but only one devel and one main package (because they
do conflict). That makes 4 packages from your example, not 6. I don't know
where your -bin subpackage came from, but it's clearly not what David or I
are proposing.

> > > 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.
> 
> That's what I wrote "at least for i386/x86_64", every current or
> future multiarch system will define its primary and secondary archs
> differently.
> 
> > 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.
> 
> He doesn't *have* to, but he may *want* to.
> 
> The difference is that in the current model we have to choose for the
> user, and we seem to make the wrong choices, since every FC release
> has been redifining what we allow the user to do. So just let them
> have the full thing, so they can deploy whatever multi-scenario they
> need and we don't have to care about stuff beginning with multi
> anymore.

So now you're talking about full multiarch support. We can talk about
that, but that's a MAJOR change and needs a separate evaluation.

> > You install either 32bit or 64bit version and use that. Why switch
> > at all?
> 
> So you never wanted to check how mplayer on i386/x86_64 behave? FWIW
> most users install mplayer.x86_64 and when they hit on something that
> doesn't work they are desperate about getting the i386 version. Same
> for firefox until now.

yum remove mplayer && yum --enablerepo=\*i386 install mplayer. What's
the problem?

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"