On Thu, Jan 02, 2014 at 06:14:07PM +0000, Dimitri John Ledkov wrote: > The correct solution is for libtool package to be marked as > "multi-arch: allowed" without splitting this tiny package into two > even smaller packages.
This analysis makes sense as far as it goes, but the problem with it is that it neglects any consideration of libtool's dependencies. As I discovered today, it totally hoses cross-building as a result. If libtool is Multi-Arch: allowed, then everything that build-depends on it gets libtool:<host> (i.e. the architecture you're building for). Now, that initially seems like what you want, because it gives you the host-architecture /usr/bin/libtool. But it also pulls in host-architecture dependencies of libtool, which include gcc and cpp, where we must have the build-architecture versions (i.e. the architecture you're building on). Note that :native is only legal in build-dependencies, not in ordinary Depends, so it cannot be used to work around this. As a result of this, today in Ubuntu (which has the M-A: allowed change) a large pile of stuff fails to cross-build when it used to work. This is bad and I plan to revert it to something closer to the state in Debian. I strongly suggest not introducing the same breakage in Debian. We could maybe figure out some answer to this, but it might well mean annotating lots of libtool reverse-build-dependencies, possibly fiddling with dh-autoreconf, or possibly doing very delicate things to the compiler's multiarch annotations. All this seems vastly excessive to cope with the case of packages that are using libtool in the *wrong way* to start with, that is, relying on /usr/bin/libtool rather than generating one in configure. Let's not vastly multiply up the effort required to support cross-building in the cause of improving cross-building support! Apparently, though, quite a few packages do fail to build with /usr/bin/libtool split out. I don't have numbers yet - Matthias said he was going to summarise. Still, I think this will be easier to fix than trying to get an M-A: allowed libtool to work properly. If you weren't one of the people in the "thinking extremely hard about multiarch" BOF at DebConf, note that Multi-Arch: foreign denotes a point in the dependency graph where you're allowed to switch architectures, Multi-Arch: allowed denotes such a point if and only if the incoming dependency is annotated with :any, and otherwise you may not switch architectures; this holds even when you're going through an Architecture: all package, so you're allowed to do this: Package: a Architecture: i386 Depends: b Package: b Architecture: all Depends: c Package: c Architecture: i386 ... but not this: Package: a Architecture: i386 Depends: b Package: b Architecture: all Depends: c Package: c Architecture: amd64 Bearing that in mind, let's go back to Kurt's options in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682045#22, elaborated a bit: 1: split most of libtool out to libtool-dev (Architecture: all, M-A: foreign); leave /usr/bin/libtool in libtool; make libtool depend on libtool-dev Workable for cross-building. Nobody needs to change; native builds will remain as before, while cross-builds will get libtool:<host>, libtool-dev, and build-architecture dependencies of libtool-dev. In this case, it is vitally important to make sure that libtool-dev is M-A: foreign as well as Architecture: all and that all libtool's existing dependencies (with the possible exception of libc-dev) are moved to libtool-dev; this will mean that apt will prefer the build architecture for these dependencies even when libtool is being installed from the host architecture. libtool could either be M-A: none or allowed. I'd be inclined to go with none, just because I can't see a clear reason to want the build-architecture version at all and it seems like a bit of a footgun, but I think either would technically work. 2.1: split /usr/bin/libtool out to libtool-bin (M-A: none or maybe allowed); make libtool depend on libtool-bin It seems to be difficult to make this work properly with cross-building. The two choices for libtool are to mark it M-A: allowed or M-A: foreign (or leave it unset, in which case you basically get one or the other behaviour depending on #666772, so let's ignore that). With M-A: allowed, there is nowhere to put the compiler dependencies that will be resolved for the build architecture, unless you declare Build-Depends: libtool:any; but then you'll get libtool-bin:<build> rather than libtool-bin:<host>, so this is futile. With M-A: foreign, you will similarly get libtool-bin:<build> rather than libtool-bin:<host>. It might be possible, though, to have libtool M-A: foreign and Depends: libtool-bin:any, and then anyone who needed libtool-bin:<host> could add an explicit Build-Depends: libtool-bin. This ends up being no-change for native builds, and equivalent to 2.2 for cross-builds. 2.2: split /usr/bin/libtool out to libtool-bin (M-A: none or maybe allowed); no dependency from libtool to libtool-bin Workable for cross-building. Some packages using /usr/bin/libtool need to change to add a build-dependency, for both native and cross builds. 3: mark libtool M-A: allowed Theoretically workable for cross-building, but probably requires changing huge numbers of reverse-build-dependencies in order not to regress that. 4: drop /usr/bin/libtool; mark libtool Architecture: all, M-A: foreign Workable for cross-building. More correct in some sense, but some packages using /usr/bin/libtool need to have their build system re-engineered; from the point of view of effort this is strictly inferior to 2.2 (which affects the same packages but only requires a one-line change to their build-dependencies). So, ranking these from least to most effort required elsewhere in the archive, we seem to have: 1 2.1 (maybe) 2.2 4 3 Assuming the Depends: libtool-bin:any trick works, 2.1 is less effort than 2.2, but it's a good deal more complicated. Overall, I would therefore prefer option 1 (not the option I expected to prefer when I started analysing this!), because as far as I can see it will unblock cross-building for both packages that need /usr/bin/libtool and those that don't, without requiring any changes to those packages, and it won't affect native building either way. Reasoning about multiarch can be hard work and I'm running low on coffee. Would anyone like to pick holes in this analysis? Kurt, if I've persuaded you that option 1 is best, I'd be happy to run a test cross-build against some reasonable subset of packages to see how it performs, especially if anyone can think of an example package that's wedded to /usr/bin/libtool. I think it's clear that this option would have no effect on native builds and doesn't require extensive testing there. Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140109192040.ga4...@riva.ucam.org