Hi, On Thu, Apr 10, 2003 at 05:23:12PM +0200, Cyrille Chepelov wrote: > Le Thu, Apr 10, 2003, à 04:43:57PM +0200, Emile van Bergen a écrit: > > > > That way you could do something like: > > > > > > # echo x86-64 >> /etc/dpkg/legal-archs > > > # dpkg -i libgtk2-2.0-1_i386.deb > > > # dpkg -i lib64gtk2-2.0-1_x8664.deb > > > > To my untrained eye, this seems an excellent and very general solution. > > > > As a slight but positive side effect, it also seems to open the way to > > per-CPU optimized library versions; if you have a 686, you add 686 (or > > 686-cmov) to /etc/dpkg/legal-archs, and can install either > > > > libssl0.9.6-0.9.6c-2_i386.deb or > > libssl0.9.6-0.9.6c-2_i686.deb; > > That would be > lib686ssl0.9.6-0.9.6c-2_i686.deb; > or > lib686-cmovssl0.9.6-0.9.6c-2_i686-cmov.deb; > > according to Wichert's proposal (which I think will lead us to a support > nightmare, not to mention the ugliness of the naming scheme) No, for dependency-less optimizations you leave them out on purpose; that's the whole idea. You want 32-bit applications that depend on libssl0.9.6, to use either libssl0.9.6-0.9.6c-2_i386.deb or libssl0.9.6-0.9.6c-2_i686.deb; completely transparent to the depending application. I.e. every package becomes slightly virtual in the sense that multiple architectures are allowed. Only 64-bit applications would depend on lib64ssl0.9.6 (from lib64ssl0.9.6-0.9.6c-2_x8664.deb, sorry, missed the 64 in my last mail) instead of depending on libssl0.9.6, which is an entirely different package. I'll stop rambling about this now though as optimization an entirely different subject. I just wanted to second Wichert's idea. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpL528aH6Owp.pgp
Description: PGP signature