Bug#792281: texlive-latex-base: not Multi-Arch: foreign
Hi Norbert,
On Thu, Sep 17, 2015 at 03:23:26PM +0900, Norbert Preining wrote:
> sorry, I just found time to come back to this topic. Thanks for
> your explanations, but I need to confirm a few things first:
Thank you for taking the time to try and understand multiarch instead of
blindly applying M-A:foreign.
> What would be a case of a maintainer script exposing the architecture?
This is difficult to answer due to the wideness of the scope.
Furthermore, this has so few examples that it is not understood too
well. Let me give some examples instead:
* The locales package is one of the few packages which is
Architecture:all, but cannot be M-A:foreign. It exposes the
architecture of one of its dependencies (libc-bin -> localedef) via
its maintainer scripts by creating architecture-specific compiled
locale files during postinst.
* python packages generally byte compile sources to .pyc files in
postinst. Those .pyc files are architecture dependent, so we
currently don't mark any of them M-A:foreign.
There might be more ways to expose architecture like storing it in a
configuration file or modifying state files. I think that texlive*'s
maintainer scripts are reasonably safe if none of its file formats
(changed during postinst) are architecture-dependent.
> > So it all boils down on whether texlive-binaries can become M-A:foreign.
> > There the content clearly is architecture specific so the question is:
> > Does the (cmdline) API expose architecture? If yes, M-A:allowed is the
>
> What does that mean?
We have seen the dependency part above in the locales example. Despite
locales being Architecture:all, it exposes the architecture of its
dependency. Such exposure can also happen when parts of the dependency
are considered public API of the package (e.g. in case of a transitional
package).
Wrt API, I think your own answer is already very good.
> > best we can do there. The question to ask here is: Is there an
> > invocation of any of these tools such that the output depends on the
> > architecture of the binary being run?
>
> Here I can answer with *very* high probability: no. The tools
> are supposed to work independent of the aarchitecture (within
> limits, we use the same source for AIX to Windows to ARM, and
> Windows might behave differently?).
>
> Just to check: A program shipping out its build arch in the
> --version
> string or similar is *not* a problem, right?
I confirm that we generally do not consider the details of --version
output as an API difference wrt. multiarch.
> If this is the case, my guess is that the only difference that could
> come in is via libraries and sub-programs (fontocnfig etc), but
> my guess is that there are no problems.
This seems very likely. We are currently in the process of checking
whether we miss any details. At some point, we need to declare our
examination as sufficient and just add the declaration to see whether we
missed anything. For instance, Jakub Wilk later discovered that the
M-A:foreign marking of make was wrong because you can access the
(architecture dependent) library search path as a Make variable.
I have been pretending that all of texlive was M-A:foreign for the
purpose of cross building packages for a while already and never
experienced problems with that assumption.
> What about the libraries build by src:texlive-bin? Would the need
> to be moved, or is there some dh magic that is doing this?
While it would be nice to have all of src:texlive-bin multiarchified,
there is (as far as I can see) no pressing need to do so. In particular,
libraries don't have to be M-A:same in order to add M-A:foreign on
packages depending on them. That said, starting with debhelper
compatibility level 9, libraries are installed in multiarch locations.
This can be done and is useful without setting M-A:same, but is one of
the requirements for setting M-A:same.
>From your second mail:
| texlive-bin builds a different set of packages depending on the
| architecture. and also the set of binaries differs - although
| only by one.
| luajittex
| cannot be build on several archs as there is not jit support for
| it, and thus we cannot ship luajittex, and for these archs
| the libtexluajit* packages are also not build.
|
| Is this a problem for M-A?
This poses no problem. Restricting the architecture set of a binary
package is independent of its M-A marking.
> And, where does one have to add the
> M-A: foreign
> line, in the source stanza or in each package stanza?
Yes, "Multi-Arch: foreign" is simply added to the respective binary
package sections in debian/control.
> I can prepare packages and upload whatever might be useful, but
> by now I don't feel comfortable with this M-A stuff.
You are already understanding M-A stuff quite well as can be seen from
the quality of your questions.
So let me prioritize issues a bit so we don't get lost.
* Marking packages such as tex-common, texlive-base and
texlive-latex-base M-A:foreign has a very immediate benefit on cross
building and being able to mix architectures in a multiarch enabled
system.
* Moving libraries in src:texlive-bin to multiarch locations probably
is the right thing to do, but I haven't seen any negative
consequences of not doing so yet.
* Marking those libraries M-A:same probably is the right thing to do,
but since there are no non-texlive reverse dependencies (am I missing
some?), I don't see any practical problems solved.
As a rule of thumb, if a binary package does not show up in any of the
following urls (with large html contents), you probably don't need to do
anything about it.
http://bootstrap.debian.net/cross_all.html
http://bootstrap.debian.net/co_ma_same.html
http://bootstrap.debian.net/foreign_install.html
And even if it shows up (e.g. libptexenc1), the solution may be in a
different package (e.g. marking texlive-binaries M-A:foreign).
I hope that this answers most of your questions. If it doesn't, don't
hesitate to ask again. Next time, please Cc debian-cross@l.d.o to ensure
a timely answer.
Helmut
Reply to: