Re: Suppressing native compilation (short and long term)

[Eli Zaretskii <eliz@gnu.org>]

> From: Rob Browning <rlb@defaultvalue.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, Po Lu <luangruo@yahoo.com>, akrl@sdf.org,
>  monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org
> Date: Sat, 15 Oct 2022 12:21:29 -0500
> 
> > Emacs should work with an unwritable file system, but there's probably
> > code that bugs out in that situation -- but those things should be
> > fixed.
> >
> > If you have a test case that demonstrates the problem, please open a bug
> > report for that, so that we can get fixin'.
> 
> OK, so if there is (or we come to) an upstream consensus that
> HOME=/does-not-exist should work (would that be considered a subset of
> the unwritable filesystem case?), then I think that's likely sufficient
> for Debian packaging.  (That's what we were initially attempting.)

It should work, yes.  And note that the message cited here, i.e.

> Warning (initialization): Unable to create `user-emacs-directory' (~/.emacs.d/).
> Any data that would normally be written there may be lost!
> If you never want to see this message again,
> customize the variable `user-emacs-directory-warning'.

is just a warning, it shouldn't prevent Emacs from running.  And yes,
features that want to save files under ~/.emacs.d will be unable to do
so, and could signal errors, unless you redefine the variables which
hold the respective file names to point to some other place.  This is
the intended behavior, I believe.