From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: tomas@tuxteam.de Newsgroups: gmane.emacs.devel Subject: Re: Suppressing native compilation (short and long term) Date: Sun, 2 Oct 2022 17:53:46 +0200 Message-ID: References: <87bkqxf1ij.fsf@tethera.net> <8335c9dkyf.fsf@gnu.org> <83edvqafr7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lPibN9bRE79kRDQF" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19562"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 02 17:55:36 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 1of1JX-0004y3-Gc for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 17:55:35 +0200 Original-Received: from localhost ([::1]:54740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1of1JW-0006sV-I5 for ged-emacs-devel@m.gmane-mx.org; Sun, 02 Oct 2022 11:55:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52292) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of1Hr-0005Ch-Fz for emacs-devel@gnu.org; Sun, 02 Oct 2022 11:53:51 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:33788) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1of1Hp-0000i5-7h; Sun, 02 Oct 2022 11:53:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject :Cc:To:From:Date:Sender:Reply-To: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=QpOOw8UYRtcclKwAFL5OEjD9IQ20E7jNJfkubOvJrnY=; b=umvRSTh6qUTocTyfooH4RXZ+Eh /g7tVXmHc5Wyt2KhIslQQ4KHtOIB2ggPXncglLmrtn2NliM9xJXTedmcvBSE9T+abb6DFAKyvftWh R3ZSdcQ47DWrFPCkA+UL3kzkR/lslf0d4fhKH/gCpyOU33k13B93S9l7cDanl4uD//GDsBCiFz4FY OXa1bV5xI8hbZG7A/FGNXvEe30GazC6R+DajCfakLMXWv40augpUDMrCKfI6LOGLoMaGIEQbSnxXg blzE2e+/m46Gs3ZTYxI1LH28rbLwwBN3AWzwLm11rpiiT+ew0rUXV3uWNBB/vg3S7uljJXVdFIeg4 L6tjJg0g==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.94.2) (envelope-from ) id 1of1Hm-00031A-8f; Sun, 02 Oct 2022 17:53:46 +0200 Content-Disposition: inline In-Reply-To: <83edvqafr7.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:296628 Archived-At: --lPibN9bRE79kRDQF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 02, 2022 at 09:42:04AM +0300, Eli Zaretskii wrote: > > Date: Sun, 2 Oct 2022 07:58:33 +0200 > > From: > >=20 > > I see there two views: the distributor's (represented here by David's) > > and the jit's (Eli) [...] > As explained in my other message, I see no reason to make such > assumptions. There's no reason to believe that a user who installs a > package will immediately start using it [...] (NOTE Eli, I admire your patience :-) As I see from your other post, there is a confusion potential with the word "package". I was talking about Debian binary packages, which are thought for those who want to use them. For those wanting to change or build there are the source packages (which come with a convenient build "kit" enabling you to build the binary package as it comes with Debian, which is a convenient starting point for tinkering). > And even it they do, why > should we care about some extra disk space or identical files being > present? disk space is cheap, while the flexibility this allows (like > each user can have a slightly differently-configured Emacs) is > non-negligible. Definitely. I am not that much concerned about disk usage, more about a uniform "baseline" installation all users can rely on. [...] > The advantage of using JIT compilation is that this is how the > upstream project meant it to be used, and this is how the defaults are > set. Any deviation from the defaults should have a good reason, and I > submit that such good reasons can only be based on actual usage, not > on theoretical presumptions. My recommendation is to use the default > JIT manner until and unless actual problems are reported by users. I see that, and this is the one view I mention above: the .eln are but a JIT cache, and each user (or instance, if there are more than one per user) has its own. > > That does make a lot of sense in a multi-user system >=20 > Not to me, it doesn't. It makes _some_ sense, but there are other > considerations. Two views, as I said :) [HOME, user-writable space] > Exactly. So what is the problem with directories writable by all > users? User separation goes out of the window, and this is one important service the OS provides. To illustrate, one user could put malicious =2Eeln files all other users would execute. > > > 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. > >=20 > > That's all fine, but then users wouldn't profit from the pre-compiled > > .eln. >=20 > There's no profit, IME. There are only disadvantages: you are in > effect fighting against the Emacs defaults, for reasons that are > purely theoretical. I have the impression that some of that reasons are quite practical for Debian packagers. > > 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. > >=20 > > Can you do the same for .elc? >=20 > I guess you meant "with .eln files"? Yes, see > native-comp-eln-load-path, which was already mentioned here several > times. So that might be one part of the way out. Cheers --=20 tom=C3=A1s --lPibN9bRE79kRDQF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCYzm0BAAKCRAFyCz1etHa RtwUAJ90cVwL2sM/EC49HDy69g8x+RyZrgCfWtNhpmgpbUcJkT+DCTy6RvuVDmA= =nxc8 -----END PGP SIGNATURE----- --lPibN9bRE79kRDQF--