Re: How to find Multi-Arch path(s)
Guillem Jover <guillem@debian.org> writes:
> 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.
Ahh. This is the point. So, there is (in my case) no reason to put *any*
binary to /usr/lib/<arch>/iraf; they all should go to /usr/lib/iraf,
indepentent of the architecture. That means, that the main package
(f.e.) cannot be co-installed for different archs, but this is also not
required.
> * 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.
The package does not support shared libs yet -- as I said they made some
funny solutions: f.e. IRAF has its own incarnation of the libc, which is
implemented on the base of FORTRAN libs, and this lib is also called
"libc.a". To avoid using the wrong lib, this one is not linked by "-lc",
but by specifying the full path. Changing this to some shared lib
approach *and* being still compatible to third-party plugins is not
trivial and part of the longer-term evolution (depending on the success
of the package).
So, I have a development package with "libc.a" and other stuff, but also
some executables (compiler) which are arch dependent. Handling multiarch
here is probably not worth the effort -- I see no use case to have the
development environment for more than one arch co-installed, and
therefore I would put the contents (binaries and static libs) to
/usr/lib/iraf/ and mark it with "Multi-arch: no".
Would this be OK?
> 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.
Looks like as I want it. Let me repeat with my own words (just to be
sure I understand it): I have
iraf - Multi-arch: foreign, x86_64, i386, ...
iraf-sptables - Multi-arch: foreign, i386; Depends: iraf
On a x86_64 with i386 enabled, when I do an "apt install iraf-sptables",
I get iraf as x86_64 and iraf-sptables as i386. Correct?
> 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. :)
I am in contact with the Fedora astro guy, so in any case I will discuss
with him. But my fork is meant to have a chance to be included upstream,
so I will not do things that where I know they don't get accepted.
Thank you very much for your patience and your good explanations! I feel
now that I understand the multiarch idea a bit better (well, hopefully).
Best regards
Ole
Reply to: