Rob Browning <[EMAIL PROTECTED]> writes: > This change would provide an advantage for packages for which emacsen > support is just a minor additional and optional item, packages like > dpkg-dev (before dpkg-dev-el) and gettext, for example. They could > just add a dependency on emacsen-common rather than having to create a > separate package like gettext-el just to avoid pulling in an entire > version of emacs, and the emacsen-common dependency would still make > sure that emacsen-common was actually initialized and installed before > the add-on packages tried to use it.
While working on this change, I think I may have remembered why we had the original restriction. If I'm right, it was because if add-on packages are allowed to depend directly on emacsen-common (as the actual emacsen flavor packages like emacs21, xemacs21, etc. are required to), then it would be possible for an add-on package's install scripts to be run for a given flavor of emacs before that flavor has actually been configured, and it would be possible for the remove scripts to be run after the flavor of emacs has been removed. Have I gotten this right? If so, then we're going to have to either leave policy alone, and packages like gettext will have to use the the gettext-el style approach, or we're going to have to come up with another solution. Thanks -- 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
