Re: How to find Multi-Arch path(s)

[Guillem Jover <guillem@debian.org>]

Hi!

On Fri, 2017-11-24 at 09:52:23 +0100, Ole Streicher wrote:
> I want to package a software, "iraf" (with extensions) that uses some
> system dependent binaries internally. Some of the extensions will be
> available in 32 bit only, so this is a good use case for
> Multi-Arch. That means, that the binaries will go to
> 
> /usr/lib/${DEB_TARGET_MULTIARCH}/iraf

It that was to be used, then it should be DEB_HOST_MULTIARCH, the
_TARGET_ variants are for canadian cross-compilers. :) If this is not
clear from the man page, I'm happy to clarify it further.

> At run time, I would now need to get the list of paths that are
> supported by the system, in their "preferred" order (so, even from a
> binary compiled for i386, it would be preferred to call a x86_64 binary
> if that is supported on the system). This list is generally not known at
> compile time, since it depends on the details of the target system
> configuration (f.e. an architecture may be supported via a software
> emulation).
> 
> However, I could not find out how to get this list?
> 
> "dpkg --print-architecture" and "dpkg --print-foreign-architectures"
> gives only what dpkg is configured for, not what is supported as
> executable. And, it does not return the multi-arch triplet.

While there are requests to include this information, so that it can
be retrieved and used, in this case it does not seem this is what you
should be using anyway, even if it was there.

> "dpkg-architecture -q DEB_HOST_MULTIARCH" may give the host architecture
> (default, or specified by the arch name), but from the manpage and the
> package description of dpkg-dev it is not intended for runtime, but for
> package build/development.

Exactly. When one needs the matching triplet or multiarch normalized
triplet for the package's arch, that's best solved by injecting that
at build time, which is already known at that point. In most cases
when one needs to know those matching triplets for *any* arch at
run-time, that's a sign there's something wrong with the design, and
I'd recommend going back to the drawing board. :)

> So, how can I canonically (ideally from C) retrieve a sorted list of
> supported multi arch paths at runtime? Or is there another good way to
> solve this? I would think it is a standard use case for multi arch,
> isn't it?

In general if you have to modify an upstream codebase to make it
package-manager aware (be that dpkg, rpm or whatever), that to me seems
like a big red sign too. In this case I think the problem is indeed that
the original question is flawed, so there's no good answer. :)

So, going back. AFAIUI the iraf project supports plugins/extensions in
the form of executables. And some might only be available in a single
arch. If that's the case, that looks like those extensions should be
placed under a /usr/lib/iraf (or similar, perhaps even /usr/libexec if
we allowed that!), and those package be marked "Multi-Arch: foreign",
then that's the package manager's problem to choose the most
appropriate architecture for those binaries (perhaps by using the
futurable executable attribute of an arch).

Hope that helps!

Thanks,
Guillem