[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

+++ Norbert Preining [2015-09-18 16:28 +0900]:
> Hi Helmut, hi all,
> > > then again, the real problem is not mixing i386 and am64, but
> > > big-endian and little-endian systems.
> > 
> > Being endianess-aware can be a good reason for not marking something
> > M-A:foreign.
> I did check back with the tex-k development list, as well as doing
> my own experiments on gabrielli.d.o, and both sources I can confirm
> that memory dumps are architecture independent and can be used
> across systems.

Excellent. Thanks for checking that.
> Am I right that my next steps should be:
> * make all texlive arch:all packages, as well as tex-common M-A: foreign


> * switch texlive-bin to dh9 and install libs into /u/l/$arch/


> * mark texlive-bin and all the libs also M-A: foreign
>   (this step I am not sure about - where are the various M-A field values
>   defined?)

No, or at least not normally. Library packages should be marked M-A:
same (meaning that they only satisfy dependencies for things of the
same architecture)

tools packages, like texlive-binaries should be M-A:foreign (meaning that
they can satisfy foreign-arch dependencies).

If the binaries (tools) and libraries are in one package then it is
usually best to be split out into separate library and binary packages
with the above M-A markings. Alternately a combined package can be
marked 'M-A: allowed' meaning that it serves both purposes and the
depending package annotates the dependency to use it as either the
tool or the libs.

However if the libraries are only used internally then maybe the
splitting is not strictly necessary. That would require a bit more
thought (And I admit that I have not yet read back this whole bug).

Multiarch info is here:

Info for packagers: https://wiki.debian.org/Multiarch/Implementation

Spec: https://wiki.ubuntu.com/MultiarchSpec

Hopefully that clarifies things for you and we can work out what the
best approach is. I am not familar with the texlive packaging, but see
there is a texlive-bin source, which does make various library
packages (MA:same) and one binaries package (MA:foreign). Details
would need checking but that seems likely to be right.

Principal hats:  Linaro, Debian, Wookware, ARM

Reply to: