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

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

Hi Norbert,

Quoting Norbert Preining (2015-09-18 09:28:24)
> > > 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.
> 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/

given your analysis above and in your past email, that sounds reasonable.

Instead of $arch in the /usr/lib/ path we usually say $triplet because the
string is not a Debian architecture but a GNU triplet.

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

Just like the others I'm not familiar with latex packaging, but again given the
prior discussion, I think the following would work:

 - mark texlive-binaries as M-A:foreign because that package contains binaries
   in /usr/bin which (according to the research so far) do not expose their

 - libkpathsea6, libptexenc1, libsynctex1, libtexlua52 and libtexluajit2 carry
   shared libraries in /usr/lib the upgrade of src:texlive-bin to dh9 will
   install the shared libraries into the right multiarch paths
   (/usr/lib/<triplet>/) and those packages can then be marked M-A:same. Just
   remember that the files that are shared by the same packages for multiple
   architectures must be bit-by-bit identical. So
   /usr/share/doc/libsynctex1/synctex_parser_readme.txt.gz for example must not
   differ between architectures (it's probably the same). After that is done,
   it will be possible to install libkpathsea6:i386 next to libkpathsea6:amd64.
   This co-installability is very important for example for libraries required
   by wine, where people need to install libx11-6:i386 and probably still want
   to keep their libx11-6:amd64 (assuming they run amd64).

 - libkpathsea-dev, libptexenc-dev, libsynctex-dev, libtexlua52-dev,
   libtexluajit-dev carry the development headers and *.a files and a symlink
   to the shared library. *-dev packages are usually marked M-A:same as well
   and thus the same rules apply as for shared libraries: files that in a
   shared location between packages of different architecture must be
   bit-by-bit identical. The risk that they differ is a bit higher here as
   sometimes, headers carry auto-generated architecture specific information.

 - as for luatex, it did not pop up in this conversation as far as I can see,
   so it needs separate investigation. Though until somebody needs it to be
   M-A:foreign you can save some time by not multiarchifying it at all.
   Remember that adding multiarch values to packages does not make sense for
   all packages and that binary packages remaining without multiarch is totally
   fine for many packages. We only need a M-A:foreign annotation for binary
   packages that are depended upon by packages from a different architecture in
   scenarios like cross building for example.

I think at this point, it's safe enough to go forward with these annotations
and hope for the best. If something breaks, somebody will file a report and
then we know more. But to test whether a M-A:foreign annotation *really* fits
it is often required to just introduce it and wait for things to break (see the
tricky make example quoted by Helmut). Whether your M-A:same annotation breaks
is a bit more obvious and easier to test: just try to co-install the same
packages for two different architectures and see if dpkg complains or not :)

Thanks a lot for your efforts!

cheers, josch

Attachment: signature.asc
Description: signature

Reply to: