[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1106291: elpa-haskell-mode: (void-variable flymake-allowed-file-name-masks)



Control: reassign -1 dh-elpa-helper
Control: retitle -1 dh-elpa-helper: helper/remove script not running when emacsen-common and an Emacs addon are upgrading together
Control: severity -1 critical
Justification: makes unrelated software on the system break,

I think this could be one instance of the older-addon-version-left-over
issues like Bug#1099205.  I managed to find a reproducer using my
Bookworm docker instance (I think a sbuild chroot also works):

1) Install elpa-haskell-mode
,----
| # apt install --no-install-recommends elpa-haskell-mode
`----
2) Update source.list/debian.sources to Trixie
,----
| # sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources # Or /etc/apt/sources.list
`----
3) Update and upgrade
,----
| # apt update
| # apt upgrade --without-new-pkgs  # also reproducible without the option
`----
4) Notice that the directory for older version of the affected addon
   still exists and contains broken links
,----
| $ ls -l /usr/share/emacs/site-lisp/elpa/
| total 8
| drwxr-xr-x 2 root root 4096 May 23 07:08 haskell-mode-17.2snapshot
| drwxr-xr-x 2 root root 4096 May 23 07:14 haskell-mode-17.5
`----

On further debugging, I think this happens when one has Emacs,
dh-elpa-helper, and an addon installed, and try to upgrade from Bookworm
to Trixie which upgrades emacsen-common.  This combination requires the
creation of symlinks under
/usr/share/emacs/site-lisp/elpa/<package>-<version>/, and this happens
because the helper/remove script of the previous version of the addon is
not run.  (In rare case, if one only installs the addon but not Emacs,
those symlinks are not created, so this doesn't matter.)

I believe that the actually issue here is that when emacsen-common is
unpacked but not configured, the helper/remove script will not run for
any Emacs addon that was unpacked before emacsen-common is configured
that was.  As such, a minimal reproducer is to change the step 3) to the
following:

3) Update and upgrade emacsen-common and the affected package
   # apt update
   # apt install emacsen-common elpa-haskell-mode

See below for a session that exhibits the issue:
,----
| $ sudo apt install emacsen-common elpa-haskell-mode
| [..skip other informational output..]
| The following packages will be upgraded:
|   elpa-haskell-mode emacsen-common
| 2 upgraded, 0 newly installed, 0 to remove and 515 not upgraded.
| Need to get 202 kB of archives.
| After this operation, 27.6 kB of additional disk space will be used.
| Get:1 http://deb.debian.org/debian trixie/main amd64 emacsen-common all 3.0.7 [12.7 kB]
| Get:2 http://deb.debian.org/debian trixie/main amd64 elpa-haskell-mode all 17.5-2 [190 kB]
| Fetched 202 kB in 0s (9888 kB/s)
| debconf: unable to initialize frontend: Dialog
| debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78, <> line 2.)
| debconf: falling back to frontend: Readline
| (Reading database ... 46666 files and directories currently installed.)
| Preparing to unpack .../emacsen-common_3.0.7_all.deb ...
| Remove emacsen-common for emacs
| emacsen-common: Handling removal of emacsen flavor emacs
| Unpacking emacsen-common (3.0.7) over (3.0.5) ...
| Preparing to unpack .../elpa-haskell-mode_17.5-2_all.deb ...
| Unpacking elpa-haskell-mode (17.5-2) over (17.2-5) ...
| Setting up emacsen-common (3.0.7) ...
| Install emacsen-common for emacs
| emacsen-common: Handling install of emacsen flavor emacs
| Setting up elpa-haskell-mode (17.5-2) ...
| Install emacsen-common for emacs
| emacsen-common: Handling install of emacsen flavor emacs
| Install elpa-haskell-mode for emacs
| install/haskell-mode-17.5: Handling install of emacsen flavor emacs
| install/haskell-mode-17.5: byte-compiling for emacs
| Processing triggers for install-info (6.8-6+b1) ...
`----

Note that after preparing to unpack the newer version of emacse-common,
it was removed from Emacs, and before the newer version was set up,
elpa-haskell-mode was unpacked, and the helper/remove script didn't run
because there is no emacsen-common available.

Another interesting finding is that `apt dist-upgrade' is unaffected,
because in that process Emacs is upgraded and it will remove all known
addons before emacsen-common is processed, and thus not triggering this
issue.

I think this issue happens because of the recent update of
emacsen-common.  If there is no update for it we won't see this issue
(e.g. from o-o-stable to o-stable).

An obvious fix for this is to make an addon Pre-Depends (according to
the Policy[1]) on emacsen-common of the latest version so that it is
ensured that emacsen-common is configured before an addon is unpacked.
However this requires updating the policy to add a `Pre-Depends' to all
packages, and to make it worse, we need to update the emacsen-common
version each time it is updated, which obviously doesn't scale.

Because ${elpa:Depends} also contains dh-elpa-helper, I tried to make
dh-elpa-helper Pre-Depends on `emacsen-common (>= 3.0.7)', and the
several test runs seem to suggest that it works.  See below for a
working example (dh-elpa-helper 2.1.10 is my custom build with the
pre-depends):
,----
| $ sudo apt install elpa-haskell-mode ./dh-elpa-helper_2.1.10_all.deb
| [..skip other informational output..]
| The following packages will be upgraded:
|   dh-elpa-helper elpa-haskell-mode emacsen-common
| 3 upgraded, 0 newly installed, 0 to remove and 514 not upgraded.
| Need to get 202 kB/212 kB of archives.
| After this operation, 29.7 kB of additional disk space will be used.
| Do you want to continue? [Y/n]
| Get:1 /home/manphiz/Projects/debian-packaging/build-area/dh-elpa-helper_2.1.10_all.deb dh-elpa-helper all 2.1.10 [9544 B]
| Get:2 http://deb.debian.org/debian trixie/main amd64 emacsen-common all 3.0.7 [12.7 kB]
| Get:3 http://deb.debian.org/debian trixie/main amd64 elpa-haskell-mode all 17.5-2 [190 kB]
| Fetched 202 kB in 0s (6910 kB/s)
| debconf: unable to initialize frontend: Dialog
| debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78, <> line 3.)
| debconf: falling back to frontend: Readline
| (Reading database ... 46666 files and directories currently installed.)
| Preparing to unpack .../emacsen-common_3.0.7_all.deb ...
| Remove emacsen-common for emacs
| emacsen-common: Handling removal of emacsen flavor emacs
| Unpacking emacsen-common (3.0.7) over (3.0.5) ...
| Setting up emacsen-common (3.0.7) ...
| Install emacsen-common for emacs
| emacsen-common: Handling install of emacsen flavor emacs
| (Reading database ... 46667 files and directories currently installed.)
| Preparing to unpack .../dh-elpa-helper_2.1.10_all.deb ...
| Unpacking dh-elpa-helper (2.1.10) over (2.0.16) ...
| Preparing to unpack .../elpa-haskell-mode_17.5-2_all.deb ...
| Remove elpa-haskell-mode for emacs
| remove/haskell-mode-17.2snapshot: Handling removal of emacsen flavor emacs
| dh-elpa: purging flavor specific files for emacs
| Unpacking elpa-haskell-mode (17.5-2) over (17.2-5) ...
| Setting up dh-elpa-helper (2.1.10) ...
| Setting up elpa-haskell-mode (17.5-2) ...
| Install emacsen-common for emacs
| emacsen-common: Handling install of emacsen flavor emacs
| Install elpa-haskell-mode for emacs
| install/haskell-mode-17.5: Handling install of emacsen flavor emacs
| install/haskell-mode-17.5: byte-compiling for emacs
| Processing triggers for install-info (6.8-6+b1) ...
`----

Note that emacsen-common is configured before processing dh-elpa-helper
and elpa-haskell-mode, and helper/remove was run properly (notice the
"Remove elpa-haskell-mode from emacs" line).

This is also the reason why I'm reassigning to dh-elpa-helper instead of
emacsen-common.  Hopefully this is a working single point of fix.

I have created a branch `bug#1106291' that contains the fix.  The diff
can be seen at [2].  We need to bump the version on each emacsen-common
update as well.

As the fix involves using Pre-Depends, Policy suggests that it should be
discussed on debian-devel@.  Please let me know whether this fix is
acceptable, or if other fixes are better and preferred.

TIA.

[1] https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends
[2] https://salsa.debian.org/emacsen-team/dh-elpa/-/compare/master...bug%231106291?from_project_id=18920

-- 
Regards,
Xiyue Deng

Attachment: signature.asc
Description: PGP signature


Reply to: