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

Re: jadetex/texlive-lang-cyrillic: Conflicts with each other (install fails)



Dear Ohura-san, dear TeX people,

this might need a change in the basic TeX packages.

Frank Küster <frank@debian.org> wrote:

> (/usr/share/texmf-texlive/tex/latex/base/fontenc.sty
> (/usr/share/texmf/tex/latex/tipa/t3enc.def)
> (/usr/share/texmf-texlive/tex/latex/cyrillic/t2aenc.def
>
> ! LaTeX Error: Encoding scheme `' unknown.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H <return>  for immediate help.
>  ...                                              
>                                                   
> l.39 ...titution{\LastDeclaredEncoding}{cmr}{m}{n}
>
> I'll investigate this later.

So, I've tried to get some insight into this.  It boils down to what I
wrote in http://tug.org/mailman/htdig/tex-live/2007-April/013454.html

Essentially, I still do not know what goes on behind the scences and
makes the encoding unknown.  But it is clear that the Debian-specific
change that triggers the problem is that we do a "hack" and not let
jadetex load the dumped latex.fmt upon format creation, but do our
redefinition of \dump and load latex.ini.

I fear that even if we understood the cause of the undefinition, the fix
might be non-trivial.  So is there a way to use latex.fmt again?
Remember that the reason for our hack was #384334.  In this bug log, I
wrote (just think
s/tetex-base/texlive-latex-base/;s/tetex-bin/texlive-base-bin/): 

,----
| Imagine the following scenario:
| 
| - tetex-base, tetex-bin and jadetex are installed, the formats are
|   generated.
| 
| - tetex-base and -bin are updated in the same dpkg run.  Updating either
|   tetex--base or -bin requires all formats to be rebuilt (because of
|   [possible] changes in the engine's, pool files, input files, etc.), so
|   both postinst scripts will trigger a rebuild.  After unpacking and
|   before configuration, tetex-bin's configuration file
|   /etc/texmf/fmt.d/01tetex.cnf exists, but there is also a
|   /etc/texmf/fmt.d/01tetex.cnf.dpkg-new.  tetex-base will be configured
|   before tetex-bin.  Because of the dpkg-new file, update-fmtutil called
|   by tetex-base's postinst will ignore information in 01tetex.cnf, but
|   it will not ignore 40jadetex.cnf which has no dpkg-new file.
| 
| - tetex-base's postinst calls fmtutil --all, and - woosh - there's no
|   information about the latex format which jadetex wants to load.  Thus
|   fmtutil and tetex-base's postinst will fail.
| 
| The solution is to not load the pregenerated latex.fmt, but instead load
| latex.ltx in jadetex.ini
`----

And now my solution breaks.  I can think of a different solution:  When
the basic TeX packages' postinst scripts run fmtutil, they first check
whether any .dpkg-new files exist in fmt.d which belong to an other
basic TeX package.  If yes, they do nothing, because the postinst of
this package will later run fmtutil --all again.

However, that is only approximately how it would work.  In fact it is
more difficult, I fear.  If texlive-base-bin and texlive-latex-base are
upgraded in the same dpkg run, it would mean that tl-base-bin drops its
running "fmtutil --all", but tl-latex-base would only run 
"fmtutil --byfmt latex" and "fmtutil --byfmt pdflatex".

So instead of dropping "fmtutil -all" completely, we would have to do
one of two things:

- either replace --all by a list of formats, and let the postinst figure
  out which formats can be generated.  This means that it would somehow
  need to figure out, or be told about, the dependencies between formats

- or make fmtutil clever enough to not try to generate formats with
  "&format" arguments if that other format does not exist.  Depending on
  commandline options, it would stop or (in our case) issue a warning.

I haven't looked at the fmtutil code, but I think the second approach
might be better.

What do you think?

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)



Reply to: