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

Re: trigger question for tex-common



Hi Ian,

I am back from mountaineering and since nobody answered here are some
more remarks, and some questions:

On Fr, 03 Apr 2009, Ian Jackson wrote:
> > That way calls from root to update-* work as before, and only the
> > maintainer scripts will call the update-texmf-config script.
> 
> You can tell whether you're running under dpkg, too: either by having
> your maintainer scripts call
>  	update-texmf-config --maintscript language
> or some such, or by having update-texmf-config check for the
> environment variables that the new dpkg provides to maintscripts.

What would you suggest? Your idea of --maintscript looks quite fine to
me. Although -- since the update-* scripts are in fact only one and that
is already quite complicated -- I am tending towards keeping two
different commands, the new one being rather simple and easier to
maintain and fix.

On Fr, 03 Apr 2009, Norbert Preining wrote:
> > > Now if I only could test that out ...
> > 
> > Err, what are you having difficulty testing ?
> 
> A broken computer an travelling ...

ATM I am reinstalling the Debian part and will try to do some testing
during the week.

> > The update-* scripts do the following: They check if a .dpkg-new script
> > is present for a config file (in /etc/texmf/updmap.d, fmt.d, language.d)
> > and if that part of the snippet is NOT included in the final config
> > file.
> 
> !
> 
> I don't think this can be right.
> 
> >     if [ -f "${file}.dpkg-new" ]; then
> >       do_not_include_file "$file"
> >     else
> 
> I don't think testing for .dpkg-new is right.  Let me go back a step:
> why won't including the file work ?  Is it possible to detect that
> condition explicitly, or depend on something more closely associated
> with it ?
> 
> You seem to be explaining how your current (or planned) maintainer
> scripts work.  Can we leave that aside for the moment while you
> explain how (La)TeX works ?  That is, what are the various moving
> parts that (La)TeX has and what steps it requires, etc. ?

It is not LaTeX, it is only about the various output drivers, that is
dvips, pdftex, and dvipdfm(x).

Ok, here some remarks, others please correct me if I am wrong (this
should not be considered exhaustive, only give an overview):

- latex produces dvi which does not include the actual font data. There
  are programs doing that:
  . dvips translates dvi to ps, and incorporates either bitmap or
    outline fonts, depending on the config file config.ps
  . dvipdfm(x) produces pdf from dvi, and also has to incorporate the
    fonts
- pdflatex (or pdftex in general) combines the two steps, ie does the
  typesetting *and* incorporate the fonts.

Now, those three *output* drivers: dvips, dvipdmf(x), pdftex do have
traditionally different config syntax. Not much of a difference, but
there is.

Each font package shipping type1 fonts usually ships some .map files.
These map files are in the format suitable for dvips.

Thomas Esser wrote long time ago a shell script for teTeX that does
(besides other things):
- it is configured by a config file updmap.cfg
- that config file refers to the map files
- the map files themselves include the font definition lines
- updmap reads updmap.cfg, checks that all .map files are present, reads
  all the references map files, merges the font definition lines, and
  writes out configuration files for dvips, dvipdfm(x), pdftex.

Problems arise when calling updmap in the case when updmap.cfg
references a not existing map file.

On Debian font packages ships the map files and snippets of the .cfg
file as conffiles in /etc/texmf. This is because people/systems might
have commercial variants of some fonts, might want to override etc, so
those have to be conffiles to keep config changes over upgrades.

Now the steps when updating a font package are:
- drop a new .cfg snippet in /etc/texmf/updmap.d/
- drop the new .map files (if some are added) in
  /etc/texmf/fonts/map/dvips/...
- call update-updmap that merges all the parts of /etc/texmf/updmap.d
  into one updmap.cfg file
- call updmap to genereate the final config files

Now the problems arise because map files are conffiles: Imagine to
packages with fonts being installed at the same time. If the first calls
update-updmap and that one includes the updmap.cfg snippet from a not
already configured package, then also the map files of the not already
configured package are not already installed/present. Then the call to
updmap will break, which is bad.

Same situation happens with a removed-but-not-purged package. 

Our solution since a long time is to exclude updmap.cfg snippets if the
.dpkg-new file is present to fix the first problem. And check for the
presence of /vaR/lib/texmf/updmap/$package.list for the second problem.

That worked absolutely fine.

(The same thing happens with language.d, fmtutil.d).

> I still think that the design needs some work.  The parts I don't
> understand but need to in order to make sensible suggestions are the
> (La)TeX parts.

To collect my ideas:
- maintainer scripts of font packages call update-texmf --map
  (sorry if I change names slightly, I still don't have access to what 
  I checked into the repository)
  which in turn calls dpkg-trigger texmf-updmap
- this will happen at a parallel installation of mutliple font pacmages
  several times, but only when all of them are unpacked and configured
  the trigger action of tex-common will be executed, which in turn will
  call update-updmap. This will work because now all packages shipping
  map files and updmap.cfg snippets are already configured, and then
  call updmap.

The problem in my current version with the explicite file/dir trigger is
that the trigger action is executed too early, namely *before* the other
packages are configured, thus the snippets are not included.

Mind, the call to updmap still succeeded, but it simply did not include
all referecnes to all installed map files. That caused the FTBFS bugs.

With the new layout it looks like that:
- package with fonts are configured and call the trigger
- trigger action is carried out as explained above

So, what do you think? If you have any better suggestion that would be
great, although I think that what I outlined above is not so bad.

Best wishes

Norbert

-------------------------------------------------------------------------------
Dr. Norbert Preining <preining@logic.at>        Vienna University of Technology
Debian Developer <preining@debian.org>                         Debian TeX Group
gpg DSA: 0x09C5B094      fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
"What was the self-sacrifice?"
"I jettisoned half of a much loved and I think
irreplaceable pair of shoes."
"Why was that self-sacrifice?"
"Because they were mine!" said Ford crossly.
"I think we have different value systems."
"Well mine's better."
"That's according to your... oh never mind."
                 --- Douglas Adams, The Hitchhikers Guide to the Galaxy


Reply to: