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: Fri, 30 Sep 2022 16:56:56 +0300 Message-ID: <8335c9dkyf.fsf@gnu.org> References: <87bkqxf1ij.fsf@tethera.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34331"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, akrl@sdf.org, rlb@defaultvalue.org To: David Bremner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 30 15:59:55 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 1oeGYT-0008h6-Lb for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Sep 2022 15:59:53 +0200 Original-Received: from localhost ([::1]:48886 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oeGYS-0005BH-77 for ged-emacs-devel@m.gmane-mx.org; Fri, 30 Sep 2022 09:59:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50920) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oeGVv-00029s-2v for emacs-devel@gnu.org; Fri, 30 Sep 2022 09:57:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49936) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oeGVu-00023J-8B; Fri, 30 Sep 2022 09:57:14 -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=0v8yXwNzXTJ78GksUFMMcp+MrVNsdjRzOGaADtu2jfM=; b=bzr022tLWUWw LgZGIpdlqdh9Nkc2vHbGy/lnWeaqQsM26DfWaGRoeWSoMrumN9nyZ88uirmgHEOAfvnOTORBdQ081 ASiF8ev4KBgqaAt7lJVHjOsL774VYQsTtk10RLn3j5f+eODC6aWfhX89497hb7BX6Lu6B+55Kogr9 wG/uqf4xyCnfm8rNnrIPFstvOjtfqwskWhY3LUP8y5EtqZuGAVGR9F3UwEjizag82qU9j70c6jvxy YoF8ba+C5SfUDK57RA5vVVuH/VRm863TtcspcyAY9hBX0KJC6SqPLu/vSa+dVGiI0IboT1K6vMP2F g/J1KznVOsQIY8wPG2DK8g==; Original-Received: from [87.69.77.57] (port=3229 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 1oeGVs-0007L9-2K; Fri, 30 Sep 2022 09:57:14 -0400 In-Reply-To: <87bkqxf1ij.fsf@tethera.net> (message from David Bremner on Fri, 30 Sep 2022 10:13:56 -0300) 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:296517 Archived-At: > From: David Bremner > Cc: emacs-devel@gnu.org, akrl@sdf.org, rlb@defaultvalue.org > Date: Fri, 30 Sep 2022 10:13:56 -0300 > > > > 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. 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. 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. > 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. See above: you can do the same with *.eln files, if, for some reason, they are produced by the installation. > 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. 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.