Bug#792281: texlive-latex-base: not Multi-Arch: foreign
Hi Helmut,
sorry, I just found time to come back to this topic. Thanks for
your explanations, but I need to confirm a few things first:
> A package can expose architecture via three mechanisms:
> * Content
> * Maintainer scripts
> * Dependencies
>
> For arch:all packages (such as tex-common, texlive-base,
> texlive-latex-base) only the latter two are left.
>
> Since ucf is M-A:foreign and the dpkg dep of tex-common is only there
> for maintscripts helper, the dependencies of tex-common do not expose
> architecture.
>
> For tex-common, this leaves the maintainer scripts as a potential
> source, but from a quick glance this looks sane.
What would be a case of a maintainer script exposing the architecture?
> are not M-A:foreign: tex-common (discussed above) and texlive-binaries.
> Its maintainer scripts do not appear to expose the architecture either.
Same as above.
> 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?
> 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?
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.
> Still tex-common seems like a safe candidate. Marking all of
> texlive-binaries, texlive-base and texlive-latex-base as M-A:foreign
> seems like a good idea and by doing it now we have plenty of time left
> to find issues before stretch is released. So maybe just doing it is
> right.
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?
And, where does one have to add the
M-A: foreign
line, in the source stanza or in each package stanza?
I can prepare packages and upload whatever might be useful, but
by now I don't feel comfortable with this M-A stuff.
All the best
Norbert
------------------------------------------------------------------------
PREINING, Norbert http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
------------------------------------------------------------------------
Reply to: