clone 737202 -1 reassign -1 emacsen-common 2.0.7 retitle -1 emacsen-common: incorrectly handles dependencies during emacsXX upgrade thanks
Hi Rob, Please do have a look at this one - it's messy :-/ On Fri, Jan 31, 2014 at 09:57:08PM +0900, Tatsuya Kinoshita wrote: > On January 31, 2014 at 11:33AM +0100, anbe (at debian.org) wrote: > > Install emacsen-common for emacs23 > [...] > > install/devscripts-el: Handling emacs23, logged in /tmp/elc_tCbg9i.log > > ERROR: install script from devscripts-el package failed > [...] > > devscripts.el:19:1:Error: Cannot open load file: mcharset > > It seems apel's mcharset.elc is not found when byte-compiling. > > The devscripts-el package depends on apel, so install/devscripts-el > called from devscripts-el.postinst succeed, but install/devscripts-el > called from emacsen-common or emacsen could fail as above. I've looked into this one. I've applied a temporary patch to devscripts-el to avoid compiling if apel is not compiled, but it seems to me that the source of the breakage is in emacsen-common's handling of dependencies. I thought I had figured out what was going on, but now I have no idea: I simply don't understand why emacs-install was attempting to byte-compile devscripts-el when it had been unpackage earlier on during the upgrade (and hence run the emacs-package-remove script). The only thing I can think is that maybe the wheezy version of emacsen-common's scripts didn't correctly remove the installed marker file. Anyway, I'm uploading a version of devscripts-el which patches around this bug, but it would be nice if it could be fixed "properly". This may be by using the new code in the emacs policy (about packages handling their own touch/rm of the installed marker file), but not quite understanding what happened, I'm not convinced that this will solve it. Julian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org