From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: GNU ELPA and package.el Date: Sun, 07 Apr 2019 16:31:39 -0400 Message-ID: References: <20180819204918.GA3934@ACM> <20180821162043.GA3946@ACM> <20180823213418.GA32596@ACM> <83lg8w9mt2.fsf@gnu.org> <871saoc70o.fsf@gmx.de> <87wosebzur.fsf_-_@gmx.de> <87tvnh9yg6.fsf@gmx.de> <8736myq6wo.fsf@gmx.de> <87y34o704v.fsf@Rainer.invalid> <87mul2p9m0.fsf@Rainer.invalid> <87sgut7m3o.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="71033"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 07 22:32:33 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hDESv-000INu-1c for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2019 22:32:33 +0200 Original-Received: from localhost ([127.0.0.1]:43266 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDESt-0001G0-Us for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2019 16:32:31 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39135) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDESG-0001Fk-KI for emacs-devel@gnu.org; Sun, 07 Apr 2019 16:31:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hDESF-000366-IK for emacs-devel@gnu.org; Sun, 07 Apr 2019 16:31:52 -0400 Original-Received: from [195.159.176.226] (port=50174 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hDESF-00030B-6r for emacs-devel@gnu.org; Sun, 07 Apr 2019 16:31:51 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hDESC-000HVL-Nd for emacs-devel@gnu.org; Sun, 07 Apr 2019 22:31:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:iKAsMHkQB//JNhSTwlfTVNjKc7c= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235093 Archived-At: >> Pretty much, yes (there's also the use of org-pkg.el rather than headers >> in org.el to specify the package version). > That I object to: We have proper version control now, this nonsense of > recording additional (and generally uncorrelated) version information in > version controlled files needs to be abolished. elpa.gnu.org generates the packages from the various branches of elpa.git. So I'm not sure where it should get its version info if not from version controlled files. What alternative do you suggest? >> Autoload do get redefined by subsequent `autoload`s. >> Was there a bug report for it? > I honestly don't remember… it was #10125 (thanks, Glenn), it starts some > way down into the discussion. The most sticky problem was when the old > autoload pointed to a different file and the new code had moved that > function to another, autoload would happily retrieve the old file and > then of course not get the function it was wanting to get. Hmm... IIRC since that discussion package.el was changed to try and address those problems (starting with c13baa10d55ec863d3ceaea48c6b2959ece98198, on Dec 2014). So if there are remaining issues, could you open a new bug report? >> Hmm... let's see. The needs I can imagine are: >> - prevent activation of a system-wide package. This should be very rare >> since package activation should not interfere at all, except for rare >> exceptions. So I'd argue such a need reflects a bug in the package. > I've had to circumvent the whole of site-lisp (and then re-implement 90% > of it as user init) at one time where the admins had borked all of it > for all Emacs versions when they actually only wanted to change things > for when you get an Emacs with a specific version from inside a very > specially configured environment. Took about two years for them to > clean it up. Not sure in which way that's related to the issue of system-wide ELPA packages. >> - prefer older user-installed package over newer system-wide package. >> This is likely also unusual, but definitely possible and legitimate. > Yes. One way we could do this is to always prefer the user-installed version over the system-wide one (tho, this will inevitably be somewhat brittle since we actually don't truly know which directories are "user" and which are "system", we can only approximate it e.g. by checking if we have write access or by declaring that package-user-dir is the only user directory and all others are system-wide). >>> The other thing package.el doesn't do at the moment is to "delete" >>> a package that is either built-in or installed system-wide without >>> replacing it with a user-installed (later) version. >> What would you want Emacs to do to "delete" a built-in or >> system-wide package? > More generally, being able to "delete" a package at any level (or making > it completely invisible) is immensely useful for testing. I still don't know what you mean by "delete" here. > Nothing, I wasn't talking about the elpa scripts, but how built-in > packages and package.el work and interact. Sorry if I confused you by > pegging it after that other text. I sense that you're venting a lot of frustration, but it's difficult to move forward without clear and concrete cases to discuss. Stefan