bug#57562: [PATCH] * lisp/emacs-lisp/comp.el (comp-run-async-workers): Fail more gracefully

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> > I didn't mean to say that I didn't understand how this could happen
>> > _technically_.  What I don't get is how come people let this happen,
>> > and don't pay attention until Emacs complains?  Isn't it crazy to have
>> > your home directory unwritable by your user??
>> 
>> I think in the above scenario, if you just upgraded to Emacs-28 and it's
>> hence the first time you run an Emacs with native compilation, you get
>> a home directory that's still perfectly writable, including `~/.emacs.d`
>> and it's only `~/.emacs.d/eln-cache` that's owned by root.
>
> Isn't the home directory created in a way that all its subdirectories
> inherit the access rights by default?

No, and the problem is ownership for which there's nothing equivalent
the `setgid` bit on directories.

Here's the scenario again:

- User FOO has been using his home directory for a while under Debian,
  using Emacs-27.
- /home/FOO/.emacs.d is owned by user A.
- /home/FOO/.emacs.d/eln-cache does not exist.
- User FOO does

      % su
      # apt upgrade
      ... this installs Emacs-28, yay! ...
      # emacs ...babla...

- when Emacs is started, HOME=/root and USER=FOO
- Since the new flashy Emacs-28 was built with native-compilation it
  tries to compile some files.
- Decides to store the files in `~$USER/.emacs.d/eln-cache`, hence in
  /home/FOO/.emacs.d/eln-cache.
- Hence it creates /home/FOO/.emacs.d/eln-cache, but we're running as
  root, so this dir will be owned by root :-(

> Anyway, what you describe is a bug in the distro, and should ideally
> be fixed there.

We can point fingers, but the result is still the same.

Personally, I think part of the problem is that we use ~$USER/ rather
than $HOME (but other people consider it to be a feature rather than a bug).
Other people will claim that the problem is the use of `su` rather than
`su -`.

I'm not sure we can really solve all those problems.  Maybe we should
try and refrain from creating dirs and files in `~/.emacs.d` when we
don't have the same uid, but it seems difficult to do it in a way that
doesn't introduce worse problems than it's solving.


        Stefan