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:
> > multilib design (TM) is the (un)art of splitting only the libdir for
> > archs and performing ugly hacks to cross-overwriting techniques.
>
> It's the art of splitting the libdir. The ugly hacks were an
> implementation detail which are largely unnecessary when you stop and
> actually think about it.
Well, let's not argue about what the true definition of the word
multilib is. That's why I called your version of multilib "David
... multilib".
For clarities sake let's just call mulitlib what is known as multilib
in Fedora since FC1.92 and not what we'd like it to had been, or what
gcc calls multilib, or what Solaris calls it.
> > As such the punchhole remove/install problem is an embedded issue of
> > the multilib design (TM).
>
> Not at all. It's just an aspect of the dirty hack we put in RPM to allow
> conflicting binaries to be installed. Not a fundamental problem with
> multilib at all.
See above, no need to really argue on words, let's solve the technical
parts and we can call it multiwoods or foresthouse or bin64. ;)
> > 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.
In contast the bin64 proposal does not even have to look into the
specfile (unless the specfile hardcoded /usr/bin or does other
forbidden things we already have purged away from Fedora), no
subpackage inflation, no overcmplicated intra- and interpackage
depency relations, no tadpole loop depedencies.
This is one of the rewarding moments where it pays of that we strictly
made use of macros lijke _bindir in the specfiles. Not everything will
build right into any random %_bindir definition, I'm not claiming
that, but we'll get the huge majority built w/o touching the
specfiles.
> > o still does not allow us to simply have two disting repos for both
> > arch, since we would have to filter out all bin subpackages
>
> No, because you _want_ both sets of bin subpackages available. The user
> gets to install the secondary version _if_ they want it.
>
> > o If we don't filter then we just pass the problem to all depsolvers,
> > e.g. yum, smart, apt
>
> No, those just install the primary architecture. The secondary arch only
> ever gets installed if the user specifically asks for it.
OK, then you have either a repo or two repos that by definition have
almost as many conflicting packages at file conflict level as src.rpms
exist. That's not only ugly, that breaks all package manager
expectations from low level to any depsolver planted above rpm.
That's not the clean concept w/o short-time hacks you are after.
Did I notice that bin64 does not have these issues to begin with?
bin64 is an extreme KISS approach that really does solve all multilib
pain we have been having all these years. And ir required zero support
from rpm, yum, smart, apt. And almost zero specfile rewrites. and full
flexibility to let everyone do what they want, all groups will be
satisfied.
> > 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.
If both versions are installed, either a prefix like today's "i386"
will mute the bin64 paths to stay only in the 32 bit world or calling
something with its absolute path would be the user's way to express
his choice between the 64/32 bit versions of the same binary.
> 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)
--
Axel.Thimm at ATrpms.net
Attachment:
pgpZNc9gsxzJB.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
