Re: Suppressing native compilation (short and long term)

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 2 Oct 2022 17:53:46 +0200
> From: tomas@tuxteam.de
> Cc: emacs-devel@gnu.org
> 
> > The advantage of using JIT compilation is that this is how the
> > upstream project meant it to be used, and this is how the defaults are
> > set.  Any deviation from the defaults should have a good reason, and I
> > submit that such good reasons can only be based on actual usage, not
> > on theoretical presumptions.  My recommendation is to use the default
> > JIT manner until and unless actual problems are reported by users.
> 
> I see that, and this is the one view I mention above: the .eln are but
> a JIT cache, and each user (or instance, if there are more than one
> per user) has its own.

Let me be blunt: this is currently _the_only_ view of the Emacs
project.  After a lot of deliberations, we didn't find any reasons for
alternative views.  My suggestion is to try our view before concluding
that it doesn't fit some situations.

> > Exactly.  So what is the problem with directories writable by all
> > users?
> 
> 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?

> > > That's all fine, but then users wouldn't profit from the pre-compiled
> > > .eln.
> > 
> > There's no profit, IME.  There are only disadvantages: you are in
> > effect fighting against the Emacs defaults, for reasons that are
> > purely theoretical.
> 
> I have the impression that some of that reasons are quite practical
> for Debian packagers.

I submit that those reasons were most probably derived from a broken
analogy with the *.elc files and with byte-compilation in general.
Not from actual usage experience.  Native compilation looks
deceptively similar to byte compilation, but it isn't.  So if
producing the *.eln files seems to contradict some Debian rules and
procedures, my suggestion is to talk to the upstream project, before
inventing solutions, because of 2 considerations:

  . the problems may not be real ones, only perceived ones
  . the upstream codebase might already provide solutions

> > > In a Debian-distributed Emacs (caveat: I'm compiling my own one!)
> > > there are .elc in /usr/share for all to use; due to the search path,
> > > a user still can install her own in a directory writable by that
> > > user and it will take precedence.
> > > 
> > > Can you do the same for .elc?
> > 
> > I guess you meant "with .eln files"?  Yes, see
> > native-comp-eln-load-path, which was already mentioned here several
> > times.
> 
> So that might be one part of the way out.

If one needs it.  I don't think they do, and I don't recommend going
there.