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

[Guillem Jover <guillem@debian.org>]

On Sat, 2017-11-25 at 11:36:27 +0100, Ole Streicher wrote:
> 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.

Correct.

> >   * 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).

Ugh. :)

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

Depends on who are the intended users of those libraries and for
that compiler (!?).

If those are needed to build only the iraf plugins, then Multi-Archifying
them, might make it possible to cross-build them easily. But that depends
on what all of this entails.

Personally I'd only mark a package as Multi-Arch: no in case there's
been determined that marking it with anything else would be wrong, and
that there's no other option, like package splitting and file
reorganization, etc, to make it Multi-Arch ready.

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

That depends on apt's behavior, other package manager frontends could
behave differently. In this case apt might prefer to make the
dependencies "self-contained" and pull iraf:i386, or it might prefer
to give the native version more weight. I'm not certain. In any case
you'd always be able to do:

  # apt install iraf-sptables iraf:amd64

or if you've got iraf:i386, just:

  # apt install iraf:amd64

and the package would get cross-graded.

> 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).

No problem!

Thanks,
Guillem