Re: emacs mode for running debuild, debc, and debi etc.

[Rob Browning <rlb@defaultvalue.org>]

Peter S Galbraith <p.galbraith@globetrotter.net> writes:

> The problem is for packages that are perfectly usable without emacs, but
> yet for which we byte-compile elisp files.
>
> If you don't depend on emacsen-common, installation breakage can ensue.
> I've seen it happen. 

True, but the point was that *emacsen-common* is not what you're in
theory supposed to be depending on.  As things are structured now, the
only thing I'm sure is "right" is for the package to depend on
"emacsen" or a particular set of flavors of emacs.  If a dependency on
emacsen-common happens to work, then that's just an accident at the
moment, and there are definitely situations where the install could
break (see below) -- whether or not it does break depends in part on
how each of the various emacsen maintainers arrange their packages.

If you have a little bit of emacs code that you need to byte compile
if and only if an emacsen is available and you don't want to make your
whole package depend on an emacsen, then with current policy you're
supposed to create a separate package with the emacs bits and have
that depend on emacsen, hence gettext-el, dpkg-dev-el, etc.

As I said, if this requirement is too onerous, then I can try to
allocate some time to work with everyone to come up with a proper
solution that allows us to safely lift the emacsen depedency
requirement, but I'd rather not do this unless we're sure the gains
are worth the cost.  Aside from the time involved, I'm inclined to be
pretty conservative where emacs-policy is concerned.  The problem is
fairly complicated, and it was relatively hard work to come up with
something we thought would be safe and effective.

> Santiago Vila <sanvila@unex.es> wrote last January:

Santiago and I discussed this at length, and in the end he decided to
create a separate gettext-el package which depends on emacsen, not
emacsen-common.  To elaborate on some of the problems with depending
on emacsen-common, here are some (edited) relevant parts of my side of
our conversation:

  OK, while actually implementing the change we talked about, I think
  I finally remebered why allowing packages to depend on
  emacsen-common was a potential problem.

  All of the various emacsen packages (emacs20, emacs21, xemacs20) are
  currently required to depend on emacsen-common, and add-on packages
  are required to depend on either "emacsen" or specific flavors of
  the emacsen packages.

  If I change it so that add-on packages are also allowed to depend on
  emacsen-common instead, then what's to prevent an add-on package's
  emacsen install/remove scripts from being called for a particular
  flavor of emacs, say emacs21, before emacs21 is actually fully
  configured?  I belive avoiding this possibility was the original
  justification for the current policy requirements.

and later on, when asked what might *actually* happen if an emacsen
package and an add-on package were being installed in the same apt or
dpkg run (presuming the add-on package depended on emacsen-common
rather than emacsen (or on flavors of emacs)):

  there's no way to know [what might happen].  The policy was designed
  to provide guarantees so that flavor maintainers, add-on
  maintainers, etc. knew the rules they needed to follow in order for
  things to be safe.

  One of the reasons for the current arrangement is to allow the
  emacsXY and xemacsXY packagers flexibility in the design and
  packaging of their packages.

  As it stands right now, an emacsXY or xemacsXY package maintainer
  would be well within their rights to leave emacs completely (or
  partially) broken until after the postinst fires.

We might be able to sit down and come up with an overhauled
emacs-policy that was more flexible, but I think it'll definitely take
some design and implementation work, and until then, it's probably
*not* OK for add-on packages to depend on emacsen-common.

And definitely let me know if I'm wrong about the potential problems.
Though if I am, we'll still need to audit the process before I could
say for sure that changing the rules is OK.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD