From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Bremner Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Fri, 30 Sep 2022 10:13:56 -0300 Message-ID: <87bkqxf1ij.fsf@tethera.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38638"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, akrl@sdf.org, rlb@defaultvalue.org To: eliz@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 30 16:00:47 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 1oeGZL-0009vp-Dv for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Sep 2022 16:00:47 +0200 Original-Received: from localhost ([::1]:43926 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oeGZK-000651-7G for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Sep 2022 10:00:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58672) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oeFqB-0007tL-PG for emacs-devel@gnu.org; Fri, 30 Sep 2022 09:14:08 -0400 Original-Received: from fethera.tethera.net ([198.245.60.197]:48514) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oeFq6-0002k6-Kg; Fri, 30 Sep 2022 09:14:07 -0400 Original-Received: by fethera.tethera.net (Postfix, from userid 1001) id D19AE5FBC0; Fri, 30 Sep 2022 09:13:57 -0400 (EDT) Original-Received: (nullmailer pid 3140633 invoked by uid 1000); Fri, 30 Sep 2022 13:13:56 -0000 In-Reply-To: 83k05mfacf.fsf@gnu.org Received-SPF: pass client-ip=198.245.60.197; envelope-from=david@tethera.net; helo=fethera.tethera.net 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 30 Sep 2022 09:57:41 -0400 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:296518 Archived-At: > The reason stated by Rob was that they want to prevent "writing to > user's HOME directory". I don't think I understand the rationale well > enough, and I asked some questions about it. I hope Rob will answer, > and then we could continue discussing what is reasonable for that use > case. For package builds, Debian has the following policy https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules in particular Required targets must not attempt to write outside of the unpacked source package tree. There are two exceptions. Firstly, the binary targets may write the binary packages to the parent directory of the unpacked source package tree. Secondly, required targets may write to /tmp, /var/tmp and to the directory specified by the TMPDIR environment variable, but must not depend on the contents of any of these. This restriction is intended to prevent source package builds creating and depending on state outside of themselves, thus affecting multiple independent rebuilds. In particular, the required targets must not attempt to write into HOME. Some additional byte compilation happens at package install time. 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. 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. David PS. Please CC me on any replies (that you want me to read). I'm not subscribed to the list. PPS. This reply is synthesized from "reply via email" on the archive page. Apologies in advance for any list etiquette failures.