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: Sun, 02 Oct 2022 12:57:54 -0500 Message-ID: <87tu4mm7kt.fsf@trouble.defaultvalue.org> References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83edvqafr7.fsf@gnu.org> <83h70m19yv.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="5770"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, emacs-devel@gnu.org To: chad , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 02 19:58:40 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 1of3Ee-0001Lz-0C for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 19:58:40 +0200 Original-Received: from localhost ([::1]:55640 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1of3Ec-0007pI-9Z for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 13:58:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40276) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of3Dy-00078N-Bz for emacs-devel@gnu.org; Sun, 02 Oct 2022 13:57:58 -0400 Original-Received: from defaultvalue.org ([45.33.119.55]:37454) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1of3Dw-0001UL-MF; Sun, 02 Oct 2022 13:57:57 -0400 Original-Received: from trouble.defaultvalue.org (localhost [127.0.0.1]) (Authenticated sender: rlb@defaultvalue.org) by defaultvalue.org (Postfix) with ESMTPSA id 46CBB2019F; Sun, 2 Oct 2022 12:57:55 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id C490C14E081; Sun, 2 Oct 2022 12:57:54 -0500 (CDT) In-Reply-To: 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:296664 Archived-At: chad writes: > At the risk of over-explaining due to message crossing mid-flight: the > thing you might be missing is that Debian provides a mechanism for people > to install *.elc files in a space shared by all users that is not > writable by those users, and there are people that use this provision. > Since these are used for *.elc files, it seems highly likely that they will > be desired for *.eln files. To be clear, I think there are (at least) two concerns here. First, from the Debian side, we may need some way to avoid writing files (i.e. the .eln files) to certain locations during testing, installs, etc. That problem may be solved -- via the variable that's already been mentioned. Though note that for reasons we can elaborate on if desired, it might be easier for us if the default for that variable could also be set via a corresponding environment variable, but that's a separate question. (For example, we have relevant emacs-related packages where the upstream build process runs emacs a level or two "down" (subprocess-wise), and so it'd be a lot less invasive if we could just set an environment variable to change the .eln destination, instead of having to figure out how to change each invocation of emacs in that package (and maintain those changes across future upstream versions). A second, and a separable question, is whether Debian should try to maintain system-level (root owned) .eln files the same way it does for .elc files. I consider that an open question, and it could well be that the answer ends up being "no". That's what we're trying to find out, and of course we have to begin by trying to communicate why that might be desirable. So here we are :) It's certainly the case that if the consensus here (among the upstream developers) is that we shouldn't do that, and that future choices/changes aren't likely to take that use case into consideration, then we have our answer. And that's fine. In the end, we just wanted to explain the potential use case(s), and see how the developers felt about it. Thanks -- 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