Re: Bug#682045: libtool: please mark libtool multi-arch: allowed

[Helmut Grohne <helmut@subdivi.de>]

On Thu, Jan 09, 2014 at 07:20:40PM +0000, Colin Watson wrote:
> 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:

While thinking of Arch:all packages as being somewhat "transparent" and
something to go through is convenient, this way of thinking risks to
bring in the wrong associations. From a dpkg point of view, there is a
special architecture (called native architecture, it happens to be the
architecture of the dpkg package). Now Arch:all is just an alias for
native. So the situation you pictured

>   Package: a
>   Architecture: i386
>   Depends: b
> 
>   Package: b
>   Architecture: all
>   Depends: c
> 
>   Package: c
>   Architecture: i386

may actually be disallowed if you happen to use dpkg:amd64.

This elaboration does not change any of your arguments, but I figured
I'd pick on it again, because I have seen it gotten wrong so many times
to the point of wanting to change this particular behaviour. ;-)

> 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:

Excuse my ignorance to previous discussion, but why is there no
/usr/bin/<triplet>-libtool? To me it appears that libtools is similar in
nature to a compiler in that it is executed on one architecture (build
architecture in autoconf terms) and produces material useful on a
(possibly) different architecture (host architecture). It is an
established practise to prefix such tools with their host architecture.

I recognize that libtool itself is a shell script that decides on most
of the architecture specific stuff at runtime. But this aspect makes a
transition to an architecture prefix easier, as the evaluation of $0
could be used to override the host* variables defined near its top. All
that it needs would be clever symlinking.

> Reasoning about multiarch can be hard work and I'm running low on
> coffee.  Would anyone like to pick holes in this analysis?

Having a multiarch background, but no libtool background, I tried to
understand it. I did not find any obvious flaws, but I do note that with
option 2.1, having libtool depend on libtool-bin does not conceptually
make sense to me, even though this alternative may be practically
useful.

Helmut