Re: Bug#792281: texlive-latex-base: not Multi-Arch: foreign
Hi Norbert,
On Fri, Sep 18, 2015 at 12:02:58AM +0900, Norbert Preining wrote:
> I think the prime problem is with tex-common, although you didn't
> spot it. tex-common declares an interest on some files called
> format files. TeX (and friends like metafont) create dump files,
> memory images, which are generated via the trigger mechanism of
> dpkg by tex-common's postinstall, see do_triggers which calls
> basically fmtutil-sys.
I certainly lack intimate knowledge of TeX packaging. This is the
primary reason why I didn't submit a bug with a patch. I do see the
triggers into tex-common while installing/upgrading TeX packages, but I
have no clue what they do.
> So besides the format dump files, I don't see anything where the
> arch might possibly leak in the way that it disturbs M-A. And
> 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.
> > texlive-latex-base M-A:foreign has a very immediate benefit on cross
> > building and being able to mix architectures in a multiarch enabled
> > system.
>
> I am not sure here - the format dumps are generated by tex-common
> via trigger, but the files that are used to generated the formats
> are shipped by different packages.
I mentioned this from a user's (actually cross builder's) perspective,
i.e. what would be desirable. This was not meant to imply that it is
actually correct. Sorry for the confusion.
>From a multiarch pov, triggers count equally as maintainer scripts. It
is very good that you mention them. Your knowledge of TeX is very
helpful here.
> In the case that the dump files are *not* compatbile, would it
> still make sense to decalre all the non-tex-common packages
> M-A: foreign, and only the tex-common package something else?
> I guess that does not make sense, right?
Let's distinguish two aspects here: Desirability and correctness. Having
almost everything except tex-common is probably still desirable, because
only few things depend or build-depend on it directly. Most of the
relevant dependencies are on texlive-something.
As for correctness, I am not so sure. Even though it is the tex-common
postinst that runs as a trigger, the architecture awareness needs to be
accounted to the package that invokes the trigger (like the locales
example runs code from libc-bin). So my question here would be: How are
these (potentially arch-dependent) dumps supposed to be used?
> Thanks a lot for your continous support and patience with my
> ignorant questions
Please keep this going. It makes cross builders happy.
Helmut
Reply to: