From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Sun, 2 Oct 2022 07:58:33 +0200 Message-ID: References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7DMh8cAk77Y757+P" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21403"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 02 08:01:14 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 1oes2M-0005Oc-C2 for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 08:01:14 +0200 Original-Received: from localhost ([::1]:42628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oes2L-0002C0-9R for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 02:01:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58770) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oerzr-0000JT-2N for emacs-devel@gnu.org; Sun, 02 Oct 2022 01:58:40 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:46676) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oerzp-0001gi-21 for emacs-devel@gnu.org; Sun, 02 Oct 2022 01:58:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=From:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+Ybno4lvNBZ44nK2gYQ51tDMTRzhivGETtLUU2zjbzM=; b=Z1+0vXoYtkf8fD/54HQUz+DetC 79NALx/Wh025jWind2oiTj2u2MILYE3mQAoaVwWyItYvkgCsuJQiv8aY1mSoLvAE/LnJcAJH2pTXH WdJsOuJ1ifb5pHiF8jz9CgeZI609ECFdEe5ktKoD/kQxGnFNcKILua7fSGU+wM8Xnjm7FhhAjOsJY pGCzACa9WMwKS+zVv62NBKKc+19EpBMH+t9f54wAAsBONo6Xyp3EjT3bgiONSd46avTmFAj5ukS4j nVkD94C5i8SvwRnz7LC7cT3DyT2KMhiNU40RB1IWcO6TfDxlRmQV6G8J1LPNCvto7jQFPvtNAC0lx 4z97elpQ==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.94.2) (envelope-from ) id 1oerzl-0000pZ-Cj for emacs-devel@gnu.org; Sun, 02 Oct 2022 07:58:33 +0200 Content-Disposition: inline In-Reply-To: <8335c9dkyf.fsf@gnu.org> Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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:296578 Archived-At: --7DMh8cAk77Y757+P Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 30, 2022 at 04:56:56PM +0300, Eli Zaretskii wrote: > > From: David Bremner [...] > > Some additional byte compilation happens at package install time. >=20 > 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. >=20 > See above: you can do the same with *.eln files, if, for some reason, > they are produced by the installation. >=20 > > 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. >=20 > 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 =2Eeln. 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 --=20 t >=20 --7DMh8cAk77Y757+P Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCYzkoggAKCRAFyCz1etHa RtCSAJ4l8cQN+NGC4V+MKPsobW1weatfEACeNFS4x5W89jLvR6hDpC+dncjZsVo= =Hbz/ -----END PGP SIGNATURE----- --7DMh8cAk77Y757+P--