lp://staging/ubuntu/utopic-proposed/emacsen-common

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

15. By Rob Browning <email address hidden> on 2014-05-21

* 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
  can?

  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 <email address hidden> for the report.
  (Closes: 736062)

* emacs-package-remove: remove unused context variable.

14. By Rob Browning <email address hidden> on 2014-01-13

Fix typo; add missing "-m" to mkdir call in postinst and policy.
Thanks to Stefan Lippers-Hollmann <email address hidden> for the report.
(Closes: 735155)

13. By Rob Browning <email address hidden> on 2014-01-11

* Don't use given/when syntax in emacs-install and
  emacs-package-install. It's experimental and produces warnings with
  Perl 5.18. Thanks to Guillem Jover <email address hidden> for the
  report. (Closes: 723157)

* sample-package-remove-foo: don't fail if elc_dir is already gone.
  Thanks to Kevin Ryde <email address hidden> for the suggestion.
  (Closes: 711915)

* Complain loudly if an add-on package appears to be broken. Add
  validate_add_on_pkg() to verify that an add-on package's invocations
  match its "style", and call it from emacs-package-install and
  emacs-package-remove.

* Ensure there are no duplicates in get_installed_add_on_packages()
  result.

* Check dpkg exit status when reading package status.

* emacs-install: mark emacsen flavor available before handling all the
  add-ons.

* Check for unlink errors when handling emacsen flavor installed state
  file.

* emacs-install/emacs-remove: stop messing with package installed state
  files. That was just wrong -- the installed state file only indicates
  that a package is ready to go (i.e. it's safe to start calling the
  install/remove scripts). It has nothing to do with emacsen flavors.

* emacs-install/emacs-remove: treat each add-on as old/new case-by-case.
  Whether or not an add-on package is old or new is a property of the
  package itself. The old or new status of the emacsen flavor is
  irrelevant.

* Check for unlink errors when handling an add-on's installed state
  file.

* Fix handling of add-on package installed state file. Mark an add-on
  package as ready (installed) sooner, and wait until after all of the
  relevant removals before marking an add-on as unavailable. Note that
  the state file is only intended to indicate that the package is ready
  for processing by emacsen-common.

* debian-emacs-policy: require add-on postinst/prerm to handle state
  directly. Add-on packages must now maintain their installed/<package>
  file directly from their postinst/prerm scripts. This should fix a
  race whenever emacsen-common and an add-on package are being installed
  at the same time (i.e. perhaps via "apt-get install add-on emacs24").
  If the add-on's postinst goes first, its emacsen install script won't
  be run.

* debian-emacs-policy: change conflicts requirement from "<" to "<<".

12. By Rob Browning <email address hidden> on 2012-12-12

* Don't ignore dependency install scripts in emacs-package-install. The
  previous code didn't actually update the script name properly in the
  loop where it was trying to install all of an add-on package's
  dependencies. As a result, none of the dependencies' install scripts
  were actually invoked. Thanks to Sébastien Villemot
  <email address hidden> for tracking down the problem, and providing
  the patch. (closes: #693472)

* Invoke each add-on install script correctly as new-style or old-style.
  Previously, emacs-package-install would invoke all of the add-on
  install scripts in a dependency chain as either old-style or
  new-style, based solely on whether or not the package that triggered
  the install was old-style or new-style. Now it should invoke each
  package's install script based on whether the package itself is
  new-style or old-style, as determined by the presence or absence of
  the policy-required /usr/lib/emacsen-common/packages/compat/PACKAGE
  file. Thanks to Sébastien Villemot <email address hidden> for the
  report. (closes: #693472)

11. By Rob Browning <email address hidden> on 2012-05-22

* Move #DEBHEPLER# up in the postinst to avoid an emacs complaint about
  a missing /usr/local/emacs/site-lisp during the emacsen-common package
  install script.

* Report something like "ERROR: install script from foo package failed"
  to more clearly indicate the cause of an install/remove failure.

10. By Rob Browning <email address hidden> on 2012-05-14

Install usr/local/emacs/site-lisp in the right place so debhelper will
handle it. Thanks to Vincent Lefevre <email address hidden> for the
report. (Closes: #672878)

9. By Rob Browning <email address hidden> on 2012-05-13

* Remove the requirement that add-on packages depend on emacsen or
  emacsen-common. This should eliminate the need for many of the
  trivial Debian foo-el packages, but before the dependencies can be
  removed, an add-on package must be changed to follow the updated
  debian-emacs-policy.

* Treat the failure of any add-on package install or remove script as a
  fatal error. Otherwise inter-add-on package dependencies won't be
  respected.

* Migrate to debhelper.

8. By Rob Browning <email address hidden> on 2012-02-11

* Remove vestigal dependency on bsdmainutils. Thanks to Sven Joachim
  <email address hidden> for the report. (Closes: #480894)

* Require add-on packages to create .el symlinks alongside .elc files.
  Update debian-emacs-policy to require add-on packages to install a .el
  symlink alongside each compiled .elc file. Thanks to "Karl
  M. Hegbloom" <email address hidden> for the original
  report. (Closes: #122444)

7. By Rob Browning <email address hidden> on 2010-12-01

Call mapc instead of mapcar in debian-startup.el since mapcar was only
being called for side-effects. Thanks to "Trent W. Buck"
<email address hidden> for the report. (closes: 530961)

6. By Rob Browning <email address hidden> on 2010-11-30

Don't print a message if /etc/mailname doesn't exist. Thanks to Josh
Triplett <email address hidden> for the report. (closes: 27757)