Hi Guillem,
thanks for the quick answer.
Guillem Jover <guil...@debian.org> writes:
> On Fri, 2017-11-24 at 09:52:23 +0100, Ole Streicher wrote:
>> /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.
OK; I was not sure.
>> 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.)
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).
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?
> 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.
> 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).
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.
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.
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 :-)
Best regards
Ole
