Re: How to find Multi-Arch path(s)
Hi!
On Fri, 2017-11-24 at 13:59:40 +0100, Ole Streicher wrote:
> Guillem Jover <guillem@debian.org> writes:
> > On Fri, 2017-11-24 at 09:52:23 +0100, Ole Streicher wrote:
> >> 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. :)
>
> IRAF is a quite old program (>>30 years), with some unconventional
> solutions. And it is in "maintenance mode" yet.
>
> The Multi-Arch solution upstream took is to put the binaries into
> directories
>
> /iraf/iraf/bin.linux for 32 bit Linux (x86)
> /iraf/iraf/bin.linux64 for 64 bit Linux (x86)
> /iraf/iraf/bin.macosx for 32 bit Mac OSX
> /iraf/iraf/bin.macintel for 32 bit Mac OSX
>
> (similar subdirs bin.<arch> are under /iraf/iraf/unix, /iraf/iraf/noao etc.)
This is closer to the old multilib approach, which we are trying to
deprecate. I'd completely scrap and ignore this concept from upstream.
> and then have explicit if statements "if 64-bit linux also look in
> 32-bit dirs". This is not applicable for Debian; first because of the
> FHS violation; but also because other archs are not really possible. The
> ARM architecture is however a working platform, with some use cases
> (people want to run it on their raspberry).
Exactly.
> Therefore I move everything unter /iraf/iraf to /usr/share/iraf (because
> it is arch independent), except the bin.* dirs, which in a Debian
> Multiarch environment should go into /usr/lib/<triplet>/iraf, right?
Nope, as I've mentioned on my previous mail, I'd make the executables
also arch-neutral on their pathnames.
The point is that the Multi-Arch concept in Debian is all about the
interfaces. How packages and files interface with each other, and
what is possible and allowed. Some examples:
* A script might be arch-independent in the contents sense; i.e., it
is the same on all architectures. But its interface might be
arch-dependent, because itself uses processor or kernel specific
interfaces, and its output changes depending on the architecture.
These cannot be marked as Mutli-Arch foreign.
* A compiled binary might be arch-dependent in the contents sense;
i.e., it is different on each architecture. But its interface might
be arch-independent, because it does not change independently on
where it is executed, or for what arch it was built for. These can
be marked as Multi-Arch foreign.
* A shared library that is being linked by some other package with
executables, needs to match their architecture and needs to be
coinstallable with itself, otherwise you could not install
packages of different architectures linking againts that library.
Say prog-a:i386 → libso:i386, and prog-b:amd64 → libso:amd64.
These are usually as Multi-Arch same.
There are other fancy scenarios, and there's the more complex
"allowed" value, but the examples below should cover our case here.
> > So, going back. AFAIUI the iraf project supports plugins/extensions in
> > the form of executables.
>
> Yes.
>
> > And some might only be available in a single arch.
>
> No. They are available under 32-bit archs. At least armhf and
> i386 (linux + kfreebsd). Maybe x32.
Well, ok, so arch-classes, all the same. :)
So, say, your native arch (the one dpkg was built for) is amd64,
and you have enabled i386 as a foreign arch. You then install the
main iraf package for amd64 (the default), and then want to use some
extension/plugin that is available only for 32-bit arches. apt for
example will just pull the i386 version, because it'd be marked as
Multi-Arch foreign and the dependencies would be fullfilled.
That of course means, that whoever is calling those extension should
not need to care what the arch is, because supposedly anything that
can be executed will do. And what to install is decided by the package
manager and/or the user. So that's why the executable pathnames should
be arch-neutral.
> > 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).
>
> This does not work: I have no way to execute from these binaries the
> correct 64-bit binary, since it does not know its directory (the
> multiarch dir known at compile time is i386-linux-gnu, not
> x86_64-linux-gnu).
See above, you should not need to know what arch is being executed.
> And I also don't think it is a clean way to make the place of a 32-bit
> executable dependent on whether a 64-bit executable exists. Also I would
> also like to be able to choose the 32-bit plugin even when a 64-bit one
> exists.
They shuld not care what bitness each executable is. That's the beauty
of it all, and that's one of the main reasons under the design of
Multi-Arch! :)
As long as those different plugins are on different pacakges, and are
all marked as Multi-Arch foreign, then you will be able to choose the
arch by just installing the package for that arch, or by cross-grading
it afterwards (i.e., switching iraf-plugin-foo:amd64 into
iraf-plugin-foo:i386).
> I could even think of more exotic test cases, like loading some
> qemu-aware kernel modules that enable to run armhf binaries on my intel
> machine, and then debug a small plugin for armhf -- so the list of
> supported archs may even change at runtime.
Nothing prevents that with what I mention above. It's actually already
supported, and was one of the considerations with the Multi-Arch design!
You'd just install qemu-user-binfmt, and the iraf plugin for armhf,
the rest should just work out-of-the-box, in theory.
> To me, this all looks like the perfect use case for "Why do we need
> Multi-Arch at the end?", and that's why I would like to have it
> implemented in a clean way. I don't see that the problem appears from an
> ugly upstream code either: I have no problem with heavily patching it
> (in fact, the version being packages is my own fork that significantly
> deviates from the original code base). If you think this should be
> solved upstream, please tell me how :-)
Hope my clarifications above, clarified things. And regarding upstrea,
I'd just remove the multilib support stuff. Although other distributions
and upstreams seem to still have a strange love affair with that, so,
dunno. :)
Thanks,
Guillem
Reply to: