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.
> > 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.
> 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.
--
Axel.Thimm at ATrpms.net
Attachment:
pgpeoLTqOFf1b.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
