Richard Lewis wrote:
> David Bremner wrote:
>
> > Richard Lewis writes:
> > > David Bremner wrote:
> > >
> >
> > As far as the actual bug with failing to clean up, I ran
> >
> > % systemd-nspawn --machine bullseye /usr/lib/dh-elpa/helper/remove emacs
> > dash 2.17.0
> >
> > and that cleans up the directory
> >
> > /usr/share/emacs/site-lisp/elpa/dash-2.17.0
> >
> > so the bug is at some other level of the stack. I guess I will have to
> > look at the log from the upgrade, but I haven't had a chance to do that
> > yet.
> >
>
> I was trying to understand when (and how ) your command above was intended
> to be run as part of the upgrade. I cna see that in bullseye
> /usr/lib/emacsen-common/packages/remove/elpa-dash would do it if called
> with 'emacs'. but this is never called:
>
> What happens in the 'apt upgrade' is:
>
> the old emacsen-common prerm is called ('<old prerm> upgrade
> <new-version>'):
>
> /var/lib/dpkg/info/emacsen-common.prerm upgrade 3.0.5
>
> This calls:
> /usr/lib/emacsen-common/emacs-package-remove --prerm emacsen-common
>
> This calls:
> /usr/lib/emacsen-common/packages/remove/emacsen-common
>
> and at the end it _unlinks_:
> /var/lib/emacsen-common/state/package/installed/emacsen-common@1 > Then, apt prepares to unpack elpa-dash: > > The elpa-dash prerm (from bullseye) is called as: > /var/lib/dpkg/info/elpa-dash.prerm upgrade > 2.19.1+git20220608.1.0ac1ecf+dfsg-1) > > but this starts with: > > if [ -e /var/lib/emacsen-common/state/package/installed/emacsen-common -a > -x > /usr/lib/emacsen-common/emacs-package-remove ] ; then > /usr/lib/emacsen-common/emacs-package-remove --prerm elpa-dash > > fi > > ... and so does nothing, > because /var/lib/emacsen-common/state/package/installed/emacsen-common is > gone. Oh! It's a state-related bug! I wonder if emacsen-common (old version) has been deinstalled at @1 (see above), or if the state is emacsen-common (new version) is unpacked, but unconfigured, and thus missing /var/lib/emacsen-common/state/package/installed/emacsen-common, which is presumably created as a last step during package configuration post-unpack? In other words, elpa-dash (and other...most?..all? dh-elpa-using packages) upgrades depends on having emacsen-common fully installed and configured at @1. I wonder if this can be solved in emacsen-common, or if it needs to be solved in dh-elpa and then all the dh-elpa-using packages rebuilt to generate new prerm scripts? Which do you think would be the better approach? Cheers, Nicholas
signature.asc
Description: PGP signature
