Bug#792281: texlive-latex-base: not Multi-Arch: foreign

[Helmut Grohne <helmut@subdivi.de>]

On Mon, Jul 13, 2015 at 04:28:05PM +0200, Thorsten Glaser wrote:
> Please add M-A: foreign to the relevant texlive-* packages.
> Do check with the M-A wizards (such as Helmut Grohne) for
> their correctness, though…

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.

So why did I pick on tex-common in this bug? Because it is a dependency
of texlive-latex-base. If texlive-latex-base can become m-a:foreign, so
can and should tex-common.

Another dependency is texlive-base. Of its dependencies the following
are not M-A:foreign: tex-common (discussed above) and texlive-binaries.
Its maintainer scripts do not appear to expose the architecture either.

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

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.

Helmut