From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Sat, 01 Oct 2022 11:38:54 -0500 Message-ID: <871qrrpkgx.fsf@trouble.defaultvalue.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83tu4odez7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14821"; mail-complaints-to="usenet@ciao.gmane.io" Cc: david@tethera.net, emacs-devel@gnu.org, akrl@sdf.org To: Eli Zaretskii , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 01 19:23:25 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 1oegCz-0003eO-Hj for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Oct 2022 19:23:25 +0200 Original-Received: from localhost ([::1]:38538 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oegCy-0002RL-Gv for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Oct 2022 13:23:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58202) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oefVz-0003Fn-Tj for emacs-devel@gnu.org; Sat, 01 Oct 2022 12:39:00 -0400 Original-Received: from defaultvalue.org ([45.33.119.55]:37442) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oefVx-0008Pv-TF; Sat, 01 Oct 2022 12:38:59 -0400 Original-Received: from trouble.defaultvalue.org (localhost [127.0.0.1]) (Authenticated sender: rlb@defaultvalue.org) by defaultvalue.org (Postfix) with ESMTPSA id 50F1A20189; Sat, 1 Oct 2022 11:38:55 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id CE24414E081; Sat, 1 Oct 2022 11:38:54 -0500 (CDT) In-Reply-To: <83tu4odez7.fsf@gnu.org> Received-SPF: pass client-ip=45.33.119.55; envelope-from=rlb@defaultvalue.org; helo=defaultvalue.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:296553 Archived-At: Eli Zaretskii 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