Re: emacs mode for running debuild, debc, and debi etc.
Rob Browning <rlb@defaultvalue.org> wrote:
> Peter S Galbraith <p.galbraith@globetrotter.net> writes:
>
> > Well, usually we byte-compile elisp files for all emacs flavours, and we
> > need to depend on emacsen-common for that. If you omit that, then no,
> > you don't need to depend on it.
>
> Packages aren't supposed to depend on emacsen-common directly. At
> least not according to current policy:
>
> I'm not absolutely sure we can't relax this requirement,
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.
Santiago Vila <sanvila@unex.es> wrote last January:
: The problem is that:
:
: * emacs-package-install does only work if emacsen-common has been
: previously configured (which I think it truly deserves a wishlist bug
: against emacsen-common).
:
: * Some packages, like gettext, have a *minima*l dependency on emacsen,
: which, IMHO, does not deserve a Depends field (a bug in policy if
: policy mandates a Depends), but of course a bug in gettext if we think
: policy is perfect (I don't think it is).
:
: * dpkg configures packages in an order which satisfies their dependencies.
: Since gettext does not depend on emacsen-common, dpkg sometimes tries
: to configure gettext and then emacsen-common. This is the wrong order
: and it fails, but only because emacs-package-install is not smart
: enough.
:
: * gettext does not need a Depends, it just needs a better
: emacs-package-install implementation, namely, one that does not fail
: if emacsen-common has not been configured yet.
So I have a package that depends on emacs-common for this reason, to
avoid depending on the much larger emacs. I can remove the depends if
that's the consensus.
Reply to: