On Thu, Jan 09, 2014 at 09:55:06PM +0100, Kurt Roeckx wrote: > On Thu, Jan 09, 2014 at 07:20:40PM +0000, Colin Watson wrote: > > 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. > > I'm wondering why I have: > Depends: gcc | c-compiler, cpp, libc6-dev | libc-dev, file, autotools-dev > > The file part makes sense since libtool will call it. > > The autotools-dev is because /usr/share/libtool/config/config.* > points to the files from autotools-dev. > > But the other things are ussually installed as part of > build-essential, and I don't see the real need for libtool > to Depend on them. libtool isn't going to work without them, > but I'm not sure it's libtool that should be pulling in those > dependencies. Maybe I should replace them by build-essential? > Will that change the result of any of this?
Hmm. You should probably drop cpp on general principles, because as far as I can see libtool doesn't call it directly, so there should also be no reason for it to depend on it directly. file and autotools-dev are Multi-Arch: foreign so are not problematic. libc6-dev, well, it's Multi-Arch: same and anyone doing cross-building will have that installed on all relevant architectures anyway, so who cares. That leaves gcc and I suppose you could bend the rules there. Replacing the dependencies with build-essential will make no difference; it has no Multi-Arch field, so it'll effectively just pass through the architecture-ness of dependencies - that is, depending on gcc via build-essential is no different from depending on it directly for this purpose. The only way you could dodge this would be to drop the dependency on gcc entirely, along with cpp. I agree that that would simplify matters, as it would then be safe to install libtool:<host>. It would be quite a delicate compromise. If you ever needed to add a dependency (e.g. "gcc (>= 4.9)", hypothetically), you could be out of luck; it would really require a comment in the control file to make sure that your future self or your successor maintainers didn't forget about the arrangement and break things. It would also be less good for anyone doing cross-building other than in a clean chroot. Since you can only have one libtool package installed and you're proposing not to have it be Multi-Arch: foreign, there'd be a good chance of conflicts (e.g. the effects of "apt-get install dh-autoreconf" would have to be reversed before cross-building something that build-depends on libtool, which could make local tests more complicated). I know that in general cross-builds work better in clean chroots anyway, but all other things being equal I'd like to have as few possible causes of package conflicts as possible; it just seems safer. At present the autotools toolchain is pretty much all Multi-Arch: foreign, which I've found to be rather convenient. So, yes, I think your approach might work; but I think I'd be inclined to rank it slightly below your previous option 1, because it seems rather fragile and I can see at least one potential practical problem with it, even though it would probably fix cross-building. Does that make sense to you? -- Colin Watson [cjwat...@debian.org] -- 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/20140109211802.ga9...@riva.ucam.org
