[Pkg-emacsen-addons] Bug#886024: split off anything-el related part

[H.-Dirk Schmitt]

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)