On Sun, Oct 2, 2022 at 12:13 PM Eli Zaretskii <
eliz@gnu.org> wrote:
> 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.
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).
~Chad