Change logs for emacsen-common source package in Trusty

  • emacsen-common (2.0.7) unstable; urgency=medium
    
    
      * 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)
    
     -- Rob Browning <email address hidden>  Mon, 13 Jan 2014 11:00:10 -0600
  • emacsen-common (2.0.6) unstable; urgency=low
    
    
      * 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 "<<".
    
     -- Rob Browning <email address hidden>  Sat, 11 Jan 2014 20:22:23 -0600
  • emacsen-common (2.0.5) unstable; urgency=low
    
    
      * 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)
    
     -- Rob Browning <email address hidden>  Wed, 12 Dec 2012 20:15:05 -0600