I don't know whether there is another way to ensure that an addon is
not unpacked when emacsen-common is also unpacked but not
configured/set-up. Pre-Depends on emacsen-common ensures this.
This sounds interesting. I think another possible fix is to let emacsen-common do `emacs-remove $FLAVOR' on preinst, so that the elpa directory of the old version of addon is cleaned up; and `emacs-install $FLAVOR' on postinst to handle the current version of the addon (could
be old if the newer version is not yet unpacked). This requires that an addon is not configured/set-up before emacsen-common, which seems to be
the case during my testing because an addon Depends on emacsen-common, I guess. Would be good if someone can confirm this behavior from from
`apt upgrade'.
Indeed. Policy seems to confirm the assumptions this solution requires.
I have implemented this in this RM[1], and run in my docker instance
several times to test it and it seems working. Please review.
[1] https://salsa.debian.org/rlb/deb-emacsen-common/-/merge_requests/3
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 486 |
Nodes: | 16 (2 / 14) |
Uptime: | 140:11:08 |
Calls: | 9,657 |
Calls today: | 5 |
Files: | 13,708 |
Messages: | 6,167,338 |