Re: The hated xmltex/jadetex games in combination with new tex-common

[Florent Rougon <f.rougon@free.fr>]

Ralf Stubner <ralf.stubner@web.de> wrote:

> When the jadetex format is build, iniTeX (whatever version is used ...)
> first loads latex.fmt and then some additional TeX macros to dump a new
> format. However, latex.fmt has been build from loading latex.ltx and
> dumping that. So in principle it should be possible to build jadetex.fmt
> by loading the TeX macros in latex.ltx plus the additional macros needed
> for jadetex and dumping that state.

OK, so this means redumping the latex format (without creating
latex.fmt) as part of dumping jadetex. That may make the system (much)
less fragile, but I don't think it is enough to solve all problems (see
below).

I am still considering the line:

  jadetex         etex    language.dat    &latex jadetex.ini

and thinking of what should be a good policy. As Norbert pointed out,
any package shipping the etex engine has to trigger a rebuild of the
depending formats. This can be done with a little parsing of
fmtutil.cnf, but unfortunately, it will fail in some circumstances, in
particular when latex is unusable.

So, Norbert suggested to change the line to something like:

  jadetex         etex    language.dat    jadetex.ini

and have jadetex.ini load latex.ltx itself (if I understood correctly).

The algorithm I was thinking about was:

  For every format F in fmtutil.cnf that depends[1] on a file that
  belongs to the package whose postinst is being run, do:

    Find the package p shipping F

    If p isn't configured:
      It will eventually be configured later, after all its
      dependencies, so we don't have to worry about it.
    else:
      Since p is configured, !!!all its dependencies are also
      configured!!!, therefore we can safely redump the format F.

Not too complex, but unfortunately, the part between exclamation marks
is a wrong assumption. :-|

For instance, during an upgrade, sometimes dependencies are broken:
jadetex can be configured while the package providing latex.fmt is not
(this is the case when the new version has been unpacked but not yet
configured). The proposed modification would only require that the
package providing latex be unpacked when redumping the jadetex format,
so that we have latex.ltx, but even that isn't guaranteed:

# dpkg -s ekiga

[...]

Depends: [...], libpt-plugins-alsa | libpt-plugins-oss, [...]

# dpkg --force-depends -P libpt-plugins-alsa
dpkg: libpt-plugins-alsa: dependency problems, but removing anyway as you request:
 ekiga depends on libpt-plugins-alsa | libpt-plugins-oss; however:
  Package libpt-plugins-alsa is to be removed.
  Package libpt-plugins-oss is not installed.
(Reading database ... 121353 files and directories currently installed.)
Removing libpt-plugins-alsa ...
# dpkg -s ekiga
Package: ekiga
Status: install ok installed

[...]

Even with --auto-deconfigure as in:

# dpkg --force-depends --auto-deconfigure -P libpt-plugins-alsa

I still get:

# dpkg -s ekiga
Package: ekiga
Status: install ok installed

which I don't understand (I was expecting --auto-deconfigure to
deconfigure ekiga). As Ian Jackson puts it (in #378009):

  We don't [preserve]:

     B <-Depends- C && installed(C) => installed(B)

  as an invariant in general.

This is something that bothers me and prevents me from devising a good
solution to our format-updating problem.

Well, so much for the brain dump.

> I haven't tried if this works and I am not sure if it would be better to
> load latex.ini or latex.ltx in jadetex.ini. It would be a bit slower,
> but I think we can ignore that issue.

Agreed.

  [1] For instance, the jadetex format depends on the etex engine,
      language.dat, the hyphenation patterns listed therein, latex.fmt
      (or latex.ltx with the modifcation suggested by Norbert) and
      jadetex.ini (at least).

-- 
Florent