Re: Suppressing native compilation (short and long term)

[tomas]

On Sun, Oct 02, 2022 at 07:11:52PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 2 Oct 2022 17:53:46 +0200
> > From: tomas@tuxteam.de
> > Cc: emacs-devel@gnu.org

[two views: JIT cache vs. pre-compiled .eln]

> 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.

Thanks for being blunt :-)

My whole intention was to make this difference clear, because
I had the impression that there were unspoken assumptions
making the discussion unnecessarily difficult.

> > > 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?

No. I was picking up on your "directories writable by all users".
Perhaps I misunderstood and you didn't mean common directories:
if so, please ignore.

>  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?

Perhaps nothing. With the native-comp-eln-load-path, there seems
to be a way for Debian to "do it its way"; you don't recommend
it (I still don't quite understand), and there are very strong
reasons to take your recommendations seriously.

> > > > 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:

I understand that there is a difference between .elc and .eln (the
set of dependencies is significantly bigger in the second case, for
one).

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

I can understand Debian's position here (yours too).

> > > > In a Debian-distributed Emacs [...]
> > > > there are .elc in /usr/share for all to use; due to the search path,

[...]

> > > > Can you do the same for .elc?
> > > 
> > > I guess you meant "with .eln files"?

Uh -- yes, sorry. Well spotted.

> > > 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.

Hm. I don't want to steal your time more, but... if you could illustrate
why, I'd eager to learn.

Cheers
-- 
tomás

signature.asc
Description: PGP signature