From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Wed, 05 Oct 2022 20:04:34 +0000 Message-ID: <92d8fa67a976fb6c85a5@heytings.org> References: <83sfk6ahty.fsf@gnu.org> <87v8p1aiof.fsf@melete.silentflame.com> <87v8p01lbu.fsf@yahoo.com> <83lepwvzxq.fsf@gnu.org> <871qroyog9.fsf@yahoo.com> <837d1gvt35.fsf@gnu.org> <87sfk3yl10.fsf@yahoo.com> <87o7uqtlsl.fsf@yahoo.com> <878rlu48kq.fsf@gnus.org> <83r0zmrzcx.fsf@gnu.org> <83lepuruoo.fsf@gnu.org> <92d8fa67a9a90c046b0c@heytings.org> <83czb6rrg9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29698"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 05 22:14:39 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 1ogAmr-0007Ti-QE for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 22:14:38 +0200 Original-Received: from localhost ([::1]:57842 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ogAmq-0000nL-In for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Oct 2022 16:14:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44350) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogAdD-0002sJ-9r for emacs-devel@gnu.org; Wed, 05 Oct 2022 16:04:40 -0400 Original-Received: from heytings.org ([95.142.160.155]:42020) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ogAdB-0005Lp-Fg; Wed, 05 Oct 2022 16:04:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1665000274; bh=vWMMoe/w8+AsBxtGZ6GhjBFwa7HRiK/A8EwbR5LFO4s=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=mqrxNlOJ135Yio50889wZFqQuCUFATShKZDrPSIREGLTsRDmXDWLdlaGg/ItLJj+C BH1UCMe2FAWnjPHTLaFm1yg8zf8sIl0eF9wjwMN5GdvM6DX9aANKNhgkI+8T9HtNhP 03LRlesdPtROm3/tXXrpvhq5cKeSNBhIP2+u4YR9M1lnO/5D4UtMazM1PbH20HQGP9 ltrRi6NbU+WpUxgYawp99dPQ7C6GKGKSTxYjI2KyHIRyRmNI5dSUYQ21jEAMQshN4Z 8z5rawtM3ZPTDRZDHUDx+DlNFvHnuFnjZeL+9k1D2mbpnRp2nWuRzs3R+EZKBnIWtU liSkmCbpwvLSA== In-Reply-To: <83czb6rrg9.fsf@gnu.org> Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org 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_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:297011 Archived-At: > > I agree with the above. But then why did you say that my description > was inaccurate? > I did not say that, or at least I did not mean to say that. I only tried to clarify something that seemed unclear, namely that eln files are not present in the package, but generated at installation time. It's a subtle difference, but it seems important in the current discussion. > > What you described matches what I wrote perfectly: the end result, after > installing Emacs and elpa-magit, is that the *.eln files are available > for all the *.el files and stored in shared directories. Whether those > *.eln files are produced on the system where the package is packaged or > as part of the installation is not important; the important part is that > all the *.eln files are there after the installation, and therefore > there's no need to disable JIT compilation. And yet Rob says that he > thinks there _is_ a need for disabling it. > If I understand Rob's initial message correctly, this subtle difference is relevant: > > Perhaps relevant in other contexts, but at least in the context of > Debian work, we'd like to be able to suppress all native compilation in > some contexts, or more specifically all writes to HOME (or really, to > avoid any implicit file manipulations[1]). > > One key case is package builds and package installs (whether the emacs > packages themselves, or any of the various emacs add-on packages (e.g. > elpa-*)). > > For package builds, HOME is typically set to /nonexistent (or similar), > and for package installs we don't want the install commands (preinst, > postinst, etc.), which are running as root, to write anything to /root/. > IIUC, what Rob wants is that (1) on Debian systems on which Emacs packages are built, the build process is running as root, and nothing should be written in /root, and (2) on user systems on which elpa-* packages are installed, the installation process, during which el files are compiled to elc and eln files, is running as root, and it should not write anything in /root.