Re: Suppressing native compilation (short and long term)

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Sun, 2 Oct 2022 12:13:44 -0400
> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> 
>  > Ah, I see. I was too sloppy. I was talking about Debian packages.
> 
>  That still doesn't explain it to me (I don't use Debian).  Can you
>  elaborate what kind of packages are we talking about, in the context
>  of this discussion?
> 
> Debian supports a user installing, for example, emacs+magit, via Debian 
> packages. This gets the user a
> stable, known-tested version of emacs plus the package usable on machines 
> that, for another example,
> cannot or should not connect to the internet. This is less important to 
> developers, but is an important part of
> the Debian support "contract".

Which part of the "emacs+magit" package is the "binary package"?  The
only part of that which could produce *.eln files at installation time
is Magit, right?  Because Emacs itself already comes with all the
preloaded *.eln files, and those aren't what we are talking about,
right?

And if we are talking about Magit in this example, then how come its
being bundled to Emacs change anything of what I said?

> For the record: I personally know of situations where such a setup would like 
> to use native-comp and would
> very much prefer NOT to duplicate either the eln files per-user nor the 
> effort of creating such. Whether or
> not that situation is important enough to the combination of emacs-devel and 
> debian-maintainers to justify
> effort on either side is, of course, debatable, but I am highly confident 
> that they exist (at least, did before the
> pandemic).

Please forgive me, but you cannot expect us to regard such situations
seriously as long as you don't describe them.