Rob Browning <[EMAIL PROTECTED]> wrote: > Peter S Galbraith <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
