Re: Finalizing 'inhibit-automatic-native-compilation'

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: emacs-devel@gnu.org,  Andrea Corallo <akrl@sdf.org>,  Lars Ingebrigtsen
>  <larsi@gnus.org>,  Stefan Monnier <monnier@iro.umontreal.ca>,  Rob
>  Browning <rlb@defaultvalue.org>, debian-emacsen@lists.debian.org
> Date: Wed, 01 Feb 2023 22:40:48 -0700
> 
> Debian is now relying on this environment variable.  It is going into
> our next stable release, which is already partially frozen, and it has
> already propagated to many (probably most) of our derivatives.
> We took the decision to start using the variable after Lars said it was
> going to stick around and, specifically, that it was therefore okay to
> backport it to Emacs 28.
> 
> Over in our own channels, we had actually been planning to add our own
> version of this environment variable, before it got added upstream.
> In other words, we independently came to the conclusion that a mechanism
> of this nature was what we needed; as Stefan says, one reason is that we
> need to handle invocations of Emacs deep within third party Makefiles.
> 
> In the shorter term, were it to be removed, we'd probably patch it back
> in with a DEBIAN_something name, rather than break all our packages
> again, or, rather than delaying uploading Emacs 29 to Debian.
> But in the longer term, I'm sure that we would be open to alternatives,
> if you really do want to remove the variable.

It is fine by me if Debian decides to patch Emacs to solve whatever
problems you have in your work on the distribution.  That's the
prerogative of downstream packages, and that's why we have Free
Software to begin with.

What I'm interested in is hearing the _reasons_ why you decided to go
with the environment variable, because those reasons might be
important in other uses.  Was it just the convenience, or was it
something else?

> (Just fyi, I am now co-maintaining Emacs in Debian alongside Rob.)

Congrats.