Re: Bug#682045: libtool: please mark libtool multi-arch: allowed
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 [cjwatson@ubuntu.com]
Reply to: