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