Peter S Galbraith <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
