Rob Browning writes ("Re: dpkg trigger questions (and/or broader emacs add-on
options)"):
> As an example related to the failures that precipitated all this, the
> current emacs policy requires all add-ons to depend on emacsen-common,
> and for them to call its commands at various points to handle
> installs/rebuilds and removals. i.e. emacsen-common is the
> library/subsystem that handles all the dependency ordering, etc.
>
> But that's just wrong if you can't assume much about the state (or even
> availability) of emacsen-common from those maintainer scripts, i.e. when
> we designed all this, I would never have guessed that even if you depend
> on emacsen-common, it might not actually be ready (or even unpacked)
> from say your prerm.
According to
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
the dependencies will have previously been configured and not
removed. I'm not sure what state you found they were in but I would
bet against there being a dpkg bug in this area.
> It's also perhaps worth noting that we don't actually care about
> triggers per se. I'd just started looking at them when among other
> things, I wondered if they might be able to eliminate the need for our
> own (currently a bit sketchy) dependency ordering.
I think triggers are probably a good thing to use here because of
their ability to defer and coalesce processing.
> > Realistically, E must be interested in A, so that A gets rebuilt. (We
> > don't want to do this the other way around, because that would cause
> > an emacs to be considered not-`installed` simply because some addon
> > hadn't been compiled.)
>
> Without having thought about it carefully -- that might be OK...
> i.e. it might be fine if the whole system (add-ons and flavors) comes
> out of "up to date" for a bit, as long as it re-converges eventually.
That's the basic principle behind the scheme, yes.
> > If we update E, E's postinst will need to rebuild both A and B. So
> > E's postinst needs to be able to do a topological sort of the addons,
> > so that it can compile them in the right order.
> >
> > Given that E's postinst can do the sort, it can reliably recompile
> > everything.
>
> But from E's postinst, we have no idea what state the add-ons are in?
Can't you look in the filesystem? I would do this by having E's
postinst look in /usr for what things to compile. It doesn't need to
know the dpkg status.
> And if so, and we had to be "completely conservative", the most we could
> do is rebuild any dependency graph sub-trees we could find where the
> add-ons were past their "postinst configure"s ... and then we'd have to
> ensure we get to the rest later somehow.
I don't think this is the right approach. Instead, recompile
everything that is physically present. This ought to work right for
anything that's not "half-installed", and in that case it can (and
should be) fixed by reinstalling the half-installed package's .deb.
In the meantime E's trigger run can fail. (But "half-installed" is
very rare.)
> One correct solution might involve some command we know will always "run
> last" in any given apt/dpkg run, and I'd wondered if triggers might be
> able to support that.
Sort of. Of course not every package can provide a hook that runs
last. You actually mean something more complicated.
The trigger system arranges that the hook you provide will run *again*
if it didn't run last. Ie, it must tolerate being run not-last, but
if anything *else* happens to trigger it after that, it will run
again.
I think this is the only reasonably plausible semantics (and it's
sufficient for your purposes).
> I think I have a better handle on what dpkg promises with respect to
> dependency states from maintscript invocations, i.e. generally, not
> much, in the limiting case, outside "postinst configure" (and now maybe
> "postinst triggered"). There it's likely, and as likely as it'll ever
> be, that your deps will be configured -- elsewhere, not so much.
The rules are set out in some detail in the manual. (See link above.)
> I'd also like to understand what we might be able to count on with
> respect to triggers. For example, is it plausible to put them in
> roughly the same class as "postinst configure" with respect to the
> dependencies will be available/configured there?
Yes, trigger processing is indeed "roughly in the same class" as
postinst configure from the pov of dependencies etc.
> # Overview:
>
> The general approach is to maintain relevant state files in
> /var/lib/emacsen-common/..., to manipulate those to reflect changes, and
> to then trigger all the add-ons to re-evaluate the state to accommodate
> changes (in some cases, an add-on will decide there's nothing to do).
You want to be very careful with any separate state you maintain.
That can make things significantly more complicated. By recording
state separately, you introduce the possibility of bugs where the
separately-recorded information is wrong (ie, doesn't reflect the real
state of the system).
I think you can do a simple approach, which recompiles all emacs
addons after any dpkg run, without needing any additional on-disk
state.
Ideally you'd think of any state you add as an optimisation for this
scheme. Ie, it's a cache invalidation problem. But, you might be
able to use filesystem timestamps instead.
Whatever you do, you should probably start by writing down the
invariants you are attempting to maintain, rather than diving straight
into the algorithm sketch.
> # Approach:
>
> Have an "installed" state file for each emacs flavor that's touched
> whenever that flavor is changed and only exists if the last postinst
> configure/triggered for that flavor was successful, i.e. it indicates
> whether add-ons should consider that flavor when building.
Why not do the compilation for each flavour in that flavour's trigger
processing? That way you don't need to worry about the installation
state of the flavour, because you know it from context.
(This doesn't prevent you from putting the code for the compilation
framework into a common package; the flavour's postinst can call it.)
> Whenever a flavor changes, trigger emacsen-common-add-on-assess-rebuild
> All add-ons will be sensitive to that trigger, and will use the
> installed state files to reinstall for the relevant flavors.
The trigger system works better when central packages are interested
and leaf packages do the triggering. This proposal inverts that.
I don't have time now to think through the details of this approach
but I would recommend doing it the other way.
HTH.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
