From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Sat, 01 Oct 2022 19:52:11 +0300 Message-ID: <834jwnbi6c.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83tu4odez7.fsf@gnu.org> <871qrrpkgx.fsf@trouble.defaultvalue.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32204"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org To: Rob Browning Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 01 19:27:05 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oegGW-0008Ap-QK for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Oct 2022 19:27:04 +0200 Original-Received: from localhost ([::1]:41580 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oegGV-0005Kq-Jk for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Oct 2022 13:27:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33194) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oefj4-0007A9-BG for emacs-devel@gnu.org; Sat, 01 Oct 2022 12:52:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60758) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oefj2-0001kF-Eo; Sat, 01 Oct 2022 12:52:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=KrdKxiB3MWpwsWc4PwSt5X0rk1vXL3NXFCU1Aeg+BRA=; b=rophzBCZEQG3 YUspFsSyZEUvVCXBViGNBwgEExt8HtfrLHdjeF7gV8lUkrp4tx9Xb6uDks0eLxQOsBPajmXENs67A s3ikKBV1nFauSfToRQti1nghxAyxn9Dk2jtZ3NRF82zyga6N2Zcl/IMFMZ0RK8Vsesj5YjCXp5vYg 7qguTeUdntHtKAZJRWayPUItEJ27uB7ZvqXyjsMYRP17OqEOhG5xBTYMVMN0ZVX5RysFGmyNOJc8Q bvKWjU6HnM7ce4t48zYEljPxOyVtA8jEsykWiG+5ZG2j27Lgui/9oIJsj2OwRtFUIsZ55FmIABGq7 0OBnVl/NL4TDr8jObGQsjQ==; Original-Received: from [87.69.77.57] (port=3332 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oefiz-0006DD-Mv; Sat, 01 Oct 2022 12:52:28 -0400 In-Reply-To: <871qrrpkgx.fsf@trouble.defaultvalue.org> (message from Rob Browning on Sat, 01 Oct 2022 11:38:54 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:296555 Archived-At: > From: Rob Browning > Cc: david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org > Date: Sat, 01 Oct 2022 11:38:54 -0500 > > 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. Thanks. > 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). Thanks for the background. You should know that the problems you needed to address with the *.elc files don't exist with the *.eln files. The *.eln files have version information of the Emacs to which they "belong" hard-coded into their names. That's why window.el gets compiled into something like window-0d1b8b93-7ef4271a.eln, and lives under a directory named something like 28.2-4fafb146 -- these 3 hashes encode both the Emacs binary and its version, and the original .el file's absolute file name and contents. So there's no way users will have any trouble when multiple Emacs versions are installed or when different users use different versions: the *.eln files are effectively automatically "versioned", and Emacs will only load a .eln file that was compiled for it. Moreover, as soon as some user decides to modify a .el file, the .eln file produced from it will have a different name, and if the Emacs binary changes as result of rebuilding, the new .eln file will be written to a different directory. > 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. Yes, by changing native-comp-eln-load-path you should be able to avoid writing to the home directory of the user under whose credentials the installation runs. If you need that.