Re: Suppressing native compilation (short and long term)

[tomas]

On Sun, Oct 02, 2022 at 09:42:04AM +0300, Eli Zaretskii wrote:
> > Date: Sun, 2 Oct 2022 07:58:33 +0200
> > From: <tomas@tuxteam.de>
> > 
> > I see there two views: the distributor's (represented here by David's)
> > and the jit's (Eli) [...]

> As explained in my other message, I see no reason to make such
> assumptions.  There's no reason to believe that a user who installs a
> package will immediately start using it [...]

(NOTE Eli, I admire your patience :-)

As I see from your other post, there is a confusion potential with
the word "package". I was talking about Debian binary packages, which
are thought for those who want to use them. For those wanting to
change or build there are the source packages (which come with a
convenient build "kit" enabling you to build the binary package as
it comes with Debian, which is a convenient starting point for
tinkering).

> And even it they do, why
> should we care about some extra disk space or identical files being
> present? disk space is cheap, while the flexibility this allows (like
> each user can have a slightly differently-configured Emacs) is
> non-negligible.

Definitely. I am not that much concerned about disk usage, more about
a uniform "baseline" installation all users can rely on.

[...]

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

> > That does make a lot of sense in a multi-user system
> 
> Not to me, it doesn't.  It makes _some_ sense, but there are other
> considerations.

Two views, as I said :)

[HOME, user-writable space]

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

> > > Emacs doesn't require a writable HOME, it requires a writable
> > > directory to store *.eln files.  It doesn't have to be HOME.  And once
> > > again, I still don't understand why *.eln files are produced at
> > > installation time in the first place.
> > 
> > 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.

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

Cheers
-- 
tomás

signature.asc
Description: PGP signature