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