Control: retitle -1 emacsen-addon package installation may never comes to an end
Control: severity -1 critical
Control: affects -1 = emacsen-common, elpa-company, elpa-js2-mode,
elpa-markdown-mode, elpa-systemd, elpa-yasnippet
This bug report is about the failed error handling in installing emacsen-addons
like *elpa-markdown-mode* or
*elpa-yasnippet*, et. al..
Especially all addons using this code fragment in there installer.
````
${FLAVOR} -q -batch -l package \
--eval "(add-to-list 'package-directory-list \"$src_dir\")" \
-f package-initialize -f batch-byte-compile *.el > Install.log 2>&1
```
In addition **all** addons relying on `emacs --batch` could be affected by this
bug.
What is going wrong?
--------------------
The code fragment relies on the following assumption:
**Emacs in batch mode will terminate and not getting stuck**
Why is this assumption not valid – please consult the bug #886153.
Here is described hot a stale emacs lock related to *anything-el* make emacs
--batch never terminating.
→ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886153
As a serious side effect all error messages are buried in „Install.log“ and
will not become visible until emacs
terminates – which in may case never happened.
Why is this a critical and security related problems
----------------------------------------------------
The problematic code fragment is invoked e.g. by `apt-get dist-upgrade` or
`dpkg --configure -a`.
These tasks will also got stuck without any reason displayed on the console.
So `apt-get dist-upgrade` got broken and it is likely that the user terminates
`apt-get` via kill (or simply reboot the
machine).
In this case he will be trapped in the pit, that he can't install any package
without fixing the „broken“ installation
of the emacsen-addon package via `dpkg --configure -a`.
This is also the case now for security related updates.
Affected Packages
------------------
I found the problematic code on my system in the
`/usr/lib/emacsen-common/packages/install` files for
- elpa-company
- elpa-js2-mode
- elpa-markdown-mode
- elpa-systemd
- elpa-yasnippet
A „code review“ of other packages will surely result in some more defective
packages.
How can this problem mitigated or fixed?
----------------------------------------
- A fix of bug #886153 would remove the trigger for the actual occurrence of
this problem. But what is with the next
defect in an emacs addon (or user stuff) breaking the batch processing again?
- A fix of of emacs concerning the `--batch` functionality – but this is maybe
not in scope.
See
https://www.gnu.org/software/emacs/manual/html_node/emacs/Initial-Options.html#Initial-Options
> „Functions that normally read keyboard input from the minibuffer take their
input from the terminal's standard
> input stream (stdin) instead.“
- Implement the assumption „emacs in batch mode will terminate and not getting
stuck“ in a wrapper script. See below for
a code outline.
What else is wrong with this emacsen addon installers.
------------------------------------------------------
It is may only a single line, but is is copied and paste between several
packages including the minor flaw that (see
`man emacs`) it should be `--batch` with a **double** hyphen.
Here a simple wrapper script would help to :
- avoid copy and paste errors
- simplify the fix of this bug
- simple reuse
Code outline for an emacs batch wrapper
----------------------------------------
Assume a bash script *emacs_batch* replacing the `-q --batch` options.
It should take as 1st option the emacs flavour (e.g. emacs25) and pass trough
all other options except `-q`,
`--no-init-file` (alias to `-q`) and `--batch`.
The emacs call could be implemented in this way:
```
declare -r catchFile=$(mktemp) # create temporary file for
output
trap rm --force ${catchFile} # and ensure cleanup
${FLAVOUR} --batch "${cmdlineOptions[@]}" &>"${catchFile}" & # fork
declare -i emacsPid=$! # and remember
sleep ${emacsTimeOut} & # fork timeout watch
declare -i sleepPid=$! # and remember
wait -n ${emacsPid} ${sleepPid} # -n → wait for the next
ending job
declare -r rc=$? # don't forget the exit code
if ! $(kill ${sleepPid})
then # oops run in timeout
… add error handling here
else # emacs terminates without
timeout
cat ${catchFile} # forward console output
exit ${rc} # rc is originating from emacs
fi
```
Note: `--batch` implies `-q`
(→
https://www.gnu.org/software/emacs/manual/html_node/emacs/Initial-Options.html#Initial-Options)
