2018-09-15 - Rob Browning <firstname.lastname@example.org>
emacsen-common (3.0.4) unstable; urgency=medium
* Conflict with xemacs21-support (<< 21.4.24-6~). Restore conflict with
xemacs21-support, but version it to exclude everything before the
emacsen-common 3.0 compatibility patches were applied. Thanks to
Adrian Bunk for reporting the issue.
2018-09-08 - Rob Browning <email@example.com>
emacsen-common (3.0.3) unstable; urgency=medium
* Don't conflict with xemacs21; it's now ready for 3.0.
* Rename emacsen-common.maintscripts to emacsen-common.maintscript.
Update rm version to 3.0.3~. (Closes: 908099, 908126)
2018-07-29 - Rob Browning <firstname.lastname@example.org>
emacsen-common (3.0.2) unstable; urgency=medium
* Move from experimental to unstable.
2018-06-30 - Rob Browning <email@example.com>
emacsen-common (3.0.1) experimental; urgency=medium
* Conflict with xemacs21 entirely until it's ready for 3.0. Thanks to
David Bremner for reporting the problem. (Closes: 902208)
* emacsen-common.maintstripts: update rm_conffile versions. Apparently
this wasn't right the first time around. Thanks to Sean Whitton for
reporting the problem and providing the fix. (Closes: 901450)
2018-05-19 - Rob Browning <firstname.lastname@example.org>
emacsen-common (3.0.0) experimental; urgency=medium
* Accommodate the unversioning of the Emacs packages, i.e. emacs25 is
* Improve sample packaging scripts (quoting, etc.).
* Remove 00debian-vars.el. Rely on flavors to set the mail-host-address
and gnus-nntpserver-file values themselves, when appropriate.
* Adjust policy to reflect dissolution of shared emacs metaflavor.
There will no longer be a shared emacs metaflavor -- the emacs25
package is planning to "unversion" to become the concrete emacs
* Update debian/compat to 10.
* Conflict with older emacsen flavors. Given the dissolution of the
emacs metaflavor and the unversioning of the emacs25 package, conflict
with the core package in all previous emacsen flavors so that we can
manage the transition without having to carry around a lot of
duplicated compatibility code here, and/or in the various flavors.
* Clean up emacsen-common install and remove.
* Move debian-startup.el to share/emacsen-common.
* Drop /etc/emacs/site-start.el.
* Remove vestigial debian-emacs-flavor handling.
* Don't run emacs/site-start.d anymore.
* Drop /usr/local/emacs/site-lisp.
2014-05-21 - Rob Browning <email@example.com>
emacsen-common (2.0.8) unstable; urgency=medium
* Require add-on packages to depend on emacsen-common >= 2.0.8. This
should be simpler and safer, and emacsen-common is only ~140k, which
shouldn't be too big a burden.
One specific problem this solves is the handling of
/var/lib/emacsen-common when emacsen-common is purged -- in particular
/var/lib/emacsen-common/state/package/installed/*. Without the
dependency, emacsen-common can't remove the tree without clobbering
the state for every add-on, but if emacsen-common can't remove it, who
This release changes the following requirements for add-on packages
(see debian-emacs-policy for the details):
- They must now depend on emacsen-common >= 2.0.8.
- They don't need to conflict with emacsen-common anymore.
- They don't need to guard their calls to emacs-install-package.
- They don't need to guard their calls to emacs-remove-package.
- They should no longer manage their package/installed/ file directly.
In addition emacsen flavor packages should now depend on
emacsen-common >= 2.0.8.
* emacs-package-install: don't try to validate the package during the preinst.
The package files that we're looking for won't be available.
Thanks to Tatsuya Kinoshita <firstname.lastname@example.org> for the report.
* emacs-package-remove: remove unused context variable.