Re: Draft spec for new dpkg "triggers" feature

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

Hi,

First, thank you very much for writing up this detailed spec.

I have a question similar to that asked by Andreas Barth. Well,
actually, after rereading my message, the question is maybe not so good
and the remainder of my mail is mostly useful for discussing with fellow
TeX maintainers how to use the trigger mechanism for TeX stuff. The
problem may apply to many other packages, though. I suggest you read the
following paragraph, and then decide for yourself whether your want to
read the rest. :)

My conclusion is that, when a package 'foo' uses a trigger to register
with package 'bar' (the one providing the update-* command), packages
depending on 'foo' working properly will generally also have to depend
on 'bar' in order to ensure that the trigger was processed *after* 'foo'
lastly activated it.

So, here we go.

Suppose (using your terminology) that producer package 'foo' has to
register with consumer package 'bar' whenever 'foo' is updated in any
significant way, and uses a trigger for this (e.g., for TeX people, a
Type 1 font package such as lmodern would trigger tex-common to run
update-udmap, mktexlsr and udmap-sys).

Now, package 'baz' comes into play and depends on 'foo' (possibly using
a versioned dependency). Currently (with current Debian Policy and
without triggers), 'baz' can mostly[1] assume that 'foo' is working
properly when its postinst is run, or after it is successfully
configured.

But, if I replace the current mechanism we have for TeX fonts with
triggers, what will ensure 'baz' that 'foo' is really working when and
after 'baz' is configured? Things may happen in this order, AFAIS:

  (1) foo is unpacked, which activates a file trigger in tex-common;
  (2) foo is configured;
  (3) baz is configured
  (4) bar eventually processes the trigger activated in step 1.

This is a problem for us TeX maintainers, because when 'baz' is
configured in step 3, 'foo' is not functional at all, as the trigger
wasn't run yet.

Concrete example:
  - foo -> lmodern (a package shipping Type 1 fonts)
  - bar -> tex-common
  - baz -> any package that uses the lmodern fonts to produce
           documents with (tex + dvips) or pdftex.

With the above sequence, 'baz' could be configured while lmodern is not
registered into updmap.cfg (or the registration information could be
out-of-date, dating from a previous lmodern version). Consequently, any
attempt in 'baz' to try to format a document with lmodern would fail,
until the trigger in tex-common is eventually run.

Do you have an idea how to avoid this problem?

Maybe 'baz' could depend on tex-common in addition to lmodern, since
tex-common's configured state would vanish as soon as the trigger is
activated.

But maybe it would be more desirable to be able to specify a dependency
on a package state that is really-really-configured, i.e., same meaning
as currently in Debian Policy, with the addition that all triggers
activated *by* the package (in the example, lmodern) must have been
processed by the triggered package(s).

Actually, having reread that, I'm not sure it's a great idea, because
the list of packages interested in the trigger can grow freely as new
packages are installed, and it is quite unclear for which interested
package the dependency should ensure that the trigger has been processed
(in the example: depending on lmodern doesn't indicate at all that what
we really want is: "interested package tex-common has processed the
trigger"; there may be a lot of other packages interested in the same
trigger, and as simple dependency on lmodern wouldn't tell for which one
of these we want to ensure the trigger has been processed).

I let the paragraph as is, because it might give others good ideas, but
I now think that for the concrete example I gave, baz should really
depend on lmodern _and_ tex-common (and of course additionally on
'texlive-base-bin | tetex-bin', in order to be able to use the
tex/dvips/pdftex binaries).

This means that, if a package 'A' (anaolog to baz) depends on, e.g.,
latex-beamer or $separate_package_providing_a_style_file for processing
documents, and these use the trigger mechanism to have tex-common run
mktexlsr, then 'A' should also depend on tex-common in order to ensure
that mktexlsr was run *after*
latex-beamer/$separate_package_providing_a_style_file was installed or
upgraded.


  [1] Only mostly, because packages 'foo' depends on might be
      deconfigured, without that affecting the "configured" state of
      'foo', IIRC.

-- 
Florent