[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: