On Mon, Aug 06, 2018 at 10:47:20PM -0500, Rob Browning wrote: > Cristian Ionescu-Idbohrn <cristian.ionescu-idbo...@axis.com> writes: > > > Setting up emacs-goodies-el (40.0) ... > > Install emacsen-common for emacs24 > > emacsen-common: Handling install of emacsen flavor emacs24 > > Wrote /etc/emacs24/site-start.d/00debian-vars.elc > > Wrote /usr/share/emacs24/site-lisp/debian-startup.elc > > Install emacsen-common for emacs25 > > emacsen-common: Handling install of emacsen flavor emacs25 > > Install emacs-goodies-el for emacs24 > > install/emacs-goodies-el: Handling emacs24, logged in > > /tmp/user/0/elc_bgxSVN.log > > Building autoloads for emacs24 in > > /usr/share/emacs24/site-lisp/emacs-goodies-el > > ERROR: install script from emacs-goodies-el package failed > > dpkg: error processing package emacs-goodies-el (--configure): > > installed emacs-goodies-el package post-installation script > > subprocess returned error exit status 1 > > I don't know for sure, but I wouldn't be surprised if the testing > version of emacs-goodies-el doesn't support older emacsXY versions > anymore. I believe the maintainers are in the process of breaking it up > with the eventual plan to remove it entirely.
Yes, this has recently come to light in testing, and for user-initiated sid2sid "apt upgrade" without "dist-upgrade". It was not revealed by piuparts stretch2sid, nor testing2sid, nor sid2sid, all of which use dist-upgrade. While examining the emacs-goodies-el side of this I found that the simplest way to resolve this issue was to add a hard dependency on emacsen-common 3.0.2 (emacs-goodies-el 40.1), but I have not yet been able to establish if unversioned emacs is also necessary. As a minimum working hypothesis: [1] packages built with emacsen-common 3.0.2 depend on emacsen-common >=3.0.2. Consequences: [2] a side-effect of upgrading foo to foo-with-[1], when emacsen-common is not first upgraded to 3.0.2 is that various legacy debian/emacsen installed as part of the *old* foo package fail to execute correctly. This is the part that doesn't make sense to me. On the upside, to the best of my knowledge packages using dh-elpa do not seem to be affected. Yes, David and I have talked about how emacs-goodies-el will eventually go away entirely. Before that occurs it will become a dummy transitional package with documentation on how to migrate away from the unmaintained parts. The emacs-goodies-el side of this transition is roughly 93% complete; however, at least five packages (maplev, matlab, color-themes-modern, and two others) need a human maintainer to take responsibility for the new elpafied package. I wonder if [2] would still occur when upgrading from a legacy to fully elpafied package? Cheers, Nicholas
signature.asc
Description: PGP signature
