Re: Suppressing native compilation (short and long term)

[tomas]

On Fri, Sep 30, 2022 at 04:56:56PM +0300, Eli Zaretskii wrote:
> > From: David Bremner <david@tethera.net>

[...]

> > Some additional byte compilation happens at package install time.
> 
> This is what I'm asking about: what exactly triggers the compilation?
> Just installing a package shouldn't do that, only loading it into
> Emacs should.

I see there two views: the distributor's (represented here by David's)
and the jit's (Eli). For Eli, the file system objects are just a long
term cache of the jit's work (longer than one Emacs session), for
David, since the package's .el (and possibly .elc) are immutable (and
of course, the whole Emacs runtime), the corresponding .eln can well
be built at package install time. That would avoid each user to have
an identical copy of them (and of course, the initial wait).

That does make a lot of sense in a multi-user system (see below for
more on that).

> The other part of what I asked is that if for some reason installation
> does need to compile files (something that I still need to understand
> why it happens), there's nothing that hard-codes HOME in the directory
> list used for that.  You can set native-comp-eln-load-path to anything
> you want, and only the directories in that list will be used.

Yes, but. It's not about HOME, but about a user-writable space. A shared
space for .eln would have to be writable by all users if the compilation
is to succeed when invoked on behalf of each one. This is a no-no under
a multiuser system.

Install is invoked as root, so it can put the results of its compilation
to a place readable by /all/ users (typically some /usr/share or /usr/lib,
depending on whether the results are architecture-independent).

> > In my
> > view the same restrictions should apply there. In addition to the
> > unintentional sharing of state mentioned in policy, there is also the
> > issue of cleaning up after a package on uninstall. This is manageable
> > now because any generated .elc files go in a package specific directory,
> > which can just be removed on purging the package.
> 
> See above: you can do the same with *.eln files, if, for some reason,
> they are produced by the installation.
> 
> > I think just turning off native compilation when HOME is not writeable
> > would be sensible from a Debian point of view. Emacs did not previously
> > require a writable HOME (although maybe most users never tested
> > this). It would be unfortunate if this changed for Emacs with native
> > compilation support.
> 
> 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. 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?

Cheers
-- 
t


>

signature.asc
Description: PGP signature