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" -- 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