Bug#586328: Bug#153860: Bug#586328: gtk-doc-tools: Upgrade fails: ERROR: emacsen-common being used before being configured.

[Rob Browning]

Josselin Mouette <joss at debian.org> writes:

> This is a serious WTF in emacsen-common and/or emacs itself. It’s not
> appropriate to add a dependency on emacsen-common just for the sake of
> including support for an editor.
>
> The bug (CCed) has been known for 8 years, so I’ll assume it won’t be
> fixed and will simply drop emacs support from gtk-doc.

Just to be clear, as far as I know, this entire bug report is if
anything a "wishlist" request.  While it's almost certainly possible to
change/improve our emacs policy, the current policy requires any package
that wants to use the debian emacs infrastructure to depend on either
emacsen, or on a specific set of emacs flavors, but not emacsen-common.

And it's not about what any given bit in the emacsen-common scripts does
or doesn't do.  It's about the express guarantee, made by
debian-emacs-policy, about when things will happen -- what will be
configured when, that emacs23 will be fully configured before any add-on
package scripts are called, etc.  Changing those guarantees would
require careful consideration of the potential effects on all of the
existing add-on packages, and on the infrastructure itself.

I'm not saying that can't be done, but rather that it's probably not as
simple as "just change this one script to make it stop complaining".


That said I'm beginning to wonder if there may actually be a different
bug in the current system.  I believe the original intent of the
dependency policy may have been to ensure that the various flavors of
emacs are fully configured before any given add-on's scripts are called.
If that's right, then imagine an add on package foo that contains
something like this:

  Depends: emacs23 | xemacs23

Presumably foo might try to byte compile itself for both flavors in its
emacsen-common install script, but I believe dpkg could be within its
rights to only configure emacs23 before trying to configure foo.  Off
the top of my head, I can't recall whether or not we considered that
when drawing up the current policy.

Much more generally, I've been wondering if a trigger based system might
work better than the current approach, but I'm not all that familiar
with triggers, so I've been reading up a bit.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4