Re: Suppressing native compilation (short and long term)

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Sun, 2 Oct 2022 12:23:43 -0400
> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> 
>  > User separation goes out of the window, and this is one important
>  > service the OS provides. To illustrate, one user could put malicious
>  > .eln files all other users would execute.
> 
>  This is about installation writing files into a shared space on disk,
>  right?  If so, this is something for the Debian packagers to figure
>  out, because doing that is their request.  And anyway, I don't
>  understand how do *.eln files are different from *.elc files, which
>  are already written to shared disk space upon installation.  What am I
>  missing?
> 
> At the risk of over-explaining due to message crossing mid-flight: the thing 
> you might be missing is that
> Debian provides a mechanism for people to install *.elc files in a space 
> shared by all users that is not
> writable by those users, and there are people that use this provision. Since 
> these are used for *.elc files, it
> seems highly likely that they will be desired for *.eln files.

No, I don't think the similar handling makes sense here.  The *.elc
files are architecture- and configuration-independent, whereas the
*.eln files are not.  E.g., the same foo.elc could be used by user A
who runs Emacs 28 and by user B who runs Emacs 29.  But the
corresponding *.eln files will be different, even though they were
produced from the same foo.el.

> Even in the face of a theoretical issue like "potential package combinations 
> make it unworkable to pre-build a
> single set of emacs+emacs-packages", the practical situation is that such 
> combinations exist and are used
> by Debian users to build a stable base of  emacs+emacs-packages that is 
> shared across users who
> cannot change that shared base (but can, of course, supplement it with their 
> own packages, via site-lisp,
> user packages, etc.) As a practical goal, there is at least *some* impetus 
> for Debian to provide such a stable
> base, and to make it as wide as reasonable. The basic mechanism for 
> determining the size of that base is
> "which emacs-packages are made into debian-packages", (iff I understand 
> correctly; I'm not a Debian
> expert).

I don't think this is relevant to the issue at hand.