On Mon, Mar 16, 2009 at 02:36:17PM +0100, Goswin von Brederlow wrote: > Aurelien Jarno <aurel...@aurel32.net> writes: > > > Goswin von Brederlow a écrit : > >> Aurelien Jarno <aurel...@aurel32.net> writes: > >> > >>> On Wed, Mar 11, 2009 at 09:55:33PM -0700, Steve Langasek wrote: > >>>> On Wed, Mar 11, 2009 at 11:16:47PM +0100, Tollef Fog Heen wrote: > >>>>> ]] Clint Adams > >>>>> | It may be time to change packages installing files to > >>>>> | /emul/ia32-linux (which violates the FHS) to use > >>>>> | /usr/lib32 instead. > >>>>> Could we pretty please use the multiarch paths here if we start moving > >>>>> stuff around? We're going to need to patch gcc/binutils if we're to > >>>>> compile stuff against those paths anyway. > >>>> What transitional issues is that going to cause us if and when multiarch > >>>> becomes generally available, if biarch packages start using the path now? > >>>> > >>> Note that i386 libc on amd64 has used once the multiarch paths. This has > >>> been reverted to the current path, because there was no clear plans > >>> about a transition to multiarch. I think this still applies. > >> > >> You couldn't compile anything for 32bit anymore. > >> > >>> One of the goal of multiarch is to avoid having packages containing > >>> binaries of a different architecture than the one of the package (e.g. > >>> i386 binaries in an amd64 package), in order to make packages of > >>> different architecture co-installable. If we start to break this goal, > >>> we will have packages using the multiarch path, but not co-installable, > >>> for example i386 libc bundled in an i386.deb and in an amd64.deb won't > >>> be co-installable. > >> > >> Already broken for 2 stable releases. > > > > We are not using multiarch paths in Debian, so this has never happens. > > When using standard /usr/lib paths, people are expecting that the paths > > collide. When using multiarch they do not expect that, as it the goal of > > multiarch. > > All biarch packages contain binary objects of a foreign architecture > (that is kind of the point of them). Some do contain binaries. Some > contain conffiles. One contains the dynamic loader. Prime example is > libc6 vs. libc6-i386/amd64. > > Using the multiarch library path already and in biarch packages just > changes the number from 5 to 25 or thereabout. > > Note that libc6 and libc6-i386/amd64 will neccessarily always conflict > due to the dynamic linker and I believe every single biarch package > depends on the libc. So they will never be coinstallable. The question > is just how much Conflicts/Replaces are needed for the upgrade path. > > >>> IMHO, we should have a clear transitional plan to multiarch before we > >>> start using multiarch path, in order to make sure we are not creating > >>> problems that has to be solved later. > >> > >> libfoo (i386) Conflicts: lib32foo, Replaces: lib32foo > >> libfoo (amd64) Conflicts: lib64foo, Replaces: lib64foo > >> > >> or > >> > >> libbla (i386) Conflicts: ia32-libs, Replaces: ia32-libs > >> libbla (amd64) Conflicts: amd63-libs, Replaces: amd64-libs > >> > >> Adding that will let dpkg know how to handle the transition just fine. > > > > Meaning we need to have that for each package previously available as a > > biarch package. Seems to be complicated for no real gain. > > > > Let me ask you a question: What would be the gain of using the multiarch > > path for the biarch packages? > > Instead of violating the FHS we would follow a hopefully future FHS > while still violating the existing FHS. So nothing really. > > I'm totaly fine with leaving the biarch packages where they are. I > would like some push behind using multiarch paths for native packages > though. Or rather I want them gone and replaced by ia32-apt-get. > > > For me pushing that is the wrong way to get multiarch support in Debian. > > If we want it, we need to move the main librairies to the multiarch > > path. And it is something I proposed for glibc once we have proper gcc > > support, and a stabilised glibc 2.9. This choice still needs to be > > validated by other persons though (like the RM team). > > Full ACK. > > > Last but not least, what is really need to have multiarch support in > > Debian is a proper support in dpkg. They are some code already done by > > Tollef, they are some ideas floating around, but they are still some > > design decisions to be taken, and nobody has a real patch that can be > > applied to dpkg. People are pushing hard to have multiarch support, but > > no one seems to care about actually writing code. > > Pre sarge we had a dpkg that could install multiarch just fine but > lacked some handholding when upgrading packages when they switched > between arch all/any. Bitrot and redesigns in dpkg have made the patch > kind of useless though and it needs to be rewritten. > > As for design decisions the only ones I know are missing are all > cosmetic. They don't imapct the algorithm, just the look&feel: > > 1) How to specify an arch in sources.list? > > Suggestion: > deb [arch=i386,amd64] http://ftp.debian.org sid main > > 2) How to specify a package including the architecture? > > Suggestions: > > Depends: foobar/i386 > Conflicts: foobar [i386] > Replaces: i386-foobar > Suggests: foobar=amd64 > > apt-get install amd64/foobar
Those both questions concerns apt. I am not sure it is the way to go. Having a working dpkg is the first way to go. Then we can start thinking about apt. > 3) Where should dpkg put maintainer scripts and package data? > > Suggestions: > > /var/lib/dpkg/info/i386/libc6.list > /var/lib/dpkg/info/i386-libc6.list > /var/lib/dpkg/info/libc6/i386.list > /var/lib/dpkg/info/libc6-i386.list > /var/lib/dpkg/info/i386/libc/libc6.list and .../info/i386/f/foobar.list What about /var/lib/dpkg/info/libc6.i386.list, as we do for a lot of stuff in debian (like debian/ directory of a package). > Do we move existing files, in case of subdirs link the current arch to > /var/lib/dpkg/info/ or do we look in both the old and new places? I think we should not try to convert anything, as it is a way to break stuff. Looking for both place should not be a big deal. > Note that apt-cross and ia32-apt-get can be used already to install > multiarch with a certain amount of hacks and failures. Converting > packages to multiarch layout would remove the need for those hacks and > remove the failures. So everything can be tested even without dpkg > having the final support for it. The final solution could even be to > just do the on-the-fly conversion of package metadata directly in apt > and dpkg without touching anything else. I do not trust on-the-fly conversion, this will only create problems. We have to add a tag to debian/control saying "multiarch compliant package". > >>> OTOH, as soon as we have the toolchain fully supporting multiarch path > >>> support (there is a missing part in gcc, that was thought to be fixed > >>> binutils [1]), I am not opposed to switch the main glibc to the multiarch > >>> path. > >>> > >>> [1] I offered to write it, but I haven't found time yet, so a patch is > >>> welcome. > >> > >> Binutils upstream has vetoed adding multiarch paths saying it is gccs > >> job. The BTS has a simple patch for gcc using the specs file to add > >> the multiarch dirs without loosing the biarch dirs. > >> > >> Did you have anything more complex in mind to fix this? > > > > This patch looks a bit hackish and it has to be done for each > > architecture. Mathias requested that something more automatic using > > debian/multiarch.inc is done. > > I'm not sure if that is sufficient: The *has to be written*, so the current version is clearly no sufficient. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
