Re: Suppressing native compilation (short and long term)

[Rob Browning <rlb@defaultvalue.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> The solution for this that I'd suggest is to precompile them, so that
> the package comes with those files already as *.eln.  That's what we
> did in Emacs 28.1 for -nw sessions, which always load the terminal
> support file from lisp/term/.

I've finally had a chance to catch up, and this thread to date appears
to cover a good bit of the relevant ground.  As requested, I'll try to
add some additional context that hopefully better explains how and why
we arrived at the current situation, asking the questions we're asking.

Long ago, we (speaking from the Debian side) came up with the Debian
Emacs policy.  This was both a policy, and the infrastructure to
implement some of it (in the form of the emacsen-common package, and
now, additionally, the dh-elpa infrastructure).

At the time, XEmacs was still active, and Emacs itself was about to
transition from 19 to 20, and my recollection is that there was a
nontrivial amount of backward incompatibility with the latter, or at
least I recall hearing from people who really didn't want to be forced
to upgrade immediately.

I'm not completely familiar with those concerns because this was just
about the time I started working on Debian's Emacs support.  In any
case, one of the key goals of that support was to allow Debian to
package, and people to install, one or more major versions of Emacs,
and/or XEmacs simultaneously.  As a result, we added support for
"emacsen flavors": emacs20, emacs21, emacs22, xemacs19, etc.  (Worth
noting that a few years back we did "unversion" the Emacs packages, so
that we no longer have emacs27, emacs28, etc., just emacs.)

We also wanted to support the creation of "add-on" packages like org,
newer versions of gnus, etc., and we wanted each of those packages to be
able to work with as many flavors (Emacs or XEmacs) as the add-on
package maintainer decided was feasible.

We wanted to have only one system-level .elc file for each flavor for
each .el file.  We did not want to have to build and maintain separate
packages for each flavor in the archive, i.e. org-emacs21, org-emacs22,
etc., each with a full set of the relevant .elc files.  (I'm also not
sure that would have worked (easily), given the versioning and
dependency concerns described next.)

We didn't want to risk breakage from backward-incompatible changes to
macros in dependencies, i.e. if the magit package depended on the foo
(library) package, we assumed we'd need to rebuild (during package
upgrade) all the majit .elc files whenever the foo package changed
because foo might have changed a macro backward incompatibly.

Since we didn't have any (reasonable?) way to detect the inter-package
dependency graph, we just insisted that those be correctly described by
the Debian package dependencies.  Then at install time, we use that
graph to determine what packages to "rebuild" (mostly just the .elc
files), and the order in which to rebuild them.

We also decided to rebuild *all* the add-on packages (.elc files) for a
given flavor whenever the version of the flavor's package changes
(e.g. when there's a new Emacs or XEmacs version) because we didn't know
whether or not any given release might make that necessary/desirable.

Uninstalling an add-on, of course, cleans up all the relevant bits
(usually, mostly just the automatically generated .elc files).

So when you "apt install elpa-magit", Debian builds all the .elc files
and puts them in the right place in /usr for every flavor you have
installed.  When you "apt install emacs" and it's a new install, Debian
builds all of the .elc files for every installed add-on package in
dependency order for that flavor.  The same thing happens during an
emacs package upgrade.

Note that we were also thinking of the case where you have a large
machine with hundreds of users (as was more often the case when we
started).  There we didn't want to have N copies of the same file for N
users (whether .elc or now .eln).

Regarding the writes to HOME, etc.  I think David covered that fairly
well -- Debian runs emacs to "do things" (build .elcs, run tests, etc.)
at package build time, package install time, and during package testing.
In all of these cases, we're likely to want to avoid side-effects outside
the build/test dir like writing .elc or .eln files to the current user's
HOME, whether that's /root/ or /home/*.  It sounds like we may be able
to accomplish that by redirecting everything to a temp dir, which is
likely fine.

Hope this helps.
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4