From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: GNU ELPA and package.el Date: Sun, 07 Apr 2019 19:37:31 +0200 Organization: Linux Private Site Message-ID: <87sgut7m3o.fsf@Rainer.invalid> 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> 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="164485"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 07 19:38:20 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 1hDBkJ-000gf0-Pa for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2019 19:38:19 +0200 Original-Received: from localhost ([127.0.0.1]:41714 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDBkI-0007fi-Im for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2019 13:38:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36014) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDBjh-0007fa-LY for emacs-devel@gnu.org; Sun, 07 Apr 2019 13:37:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hDBjg-0000JD-BZ for emacs-devel@gnu.org; Sun, 07 Apr 2019 13:37:41 -0400 Original-Received: from [195.159.176.226] (port=42452 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hDBjg-0000HN-0r for emacs-devel@gnu.org; Sun, 07 Apr 2019 13:37:40 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hDBjd-000ft0-6l for emacs-devel@gnu.org; Sun, 07 Apr 2019 19:37:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:q6Zt0N4WIcSRQ2la8RuSNqOnvpI= 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:235075 Archived-At: Stefan Monnier writes: > 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. I'm fine with generating extra files to help ELPA along, but not to alter existing files from their version-controlled state. > 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. >> I posted example code, a horrible hack of cleaning the data structures >> manually and we've discussed if it was possible to start a "clean" >> Emacs for byte compilation to work around this. > > Sorry, that doesn't ring a bell. Could you show me the bug#nb? See above, more of it was here on emacs.devel, around four years ago or even a bit earlier. The Gmane IDs unfortunately are useless now, I need to dig into the archives to get you working links… here are three mailing list threads: http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00567.html http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg00207.html http://lists.gnu.org/archive/html/emacs-devel/2016-09/msg00425.html [Btw, the search page in the mailing list archive has a bug: when you try to change the search string or the sort order it will remove the index being searched and doesn't find anything until you add it back manually.] >> Well yes, most users that can't install their own packages, but can use >> package.el would be at loss to do it via package-load-list, but are not >> expected to have problems if package.el told them which versions of a >> package are avilable on their system and where and which of thos they >> want to use (or install one from a package archive). > > 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. > - prefer older user-installed package over newer system-wide package. > This is likely also unusual, but definitely possible and legitimate. Yes. > Are there other cases? >> 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. >> The last time I tried to discuss the requirements of moving this along >> (this really ties into so many places in Emacs that hopefully we have >> clear specifications of what to implement before actually starting it) > > Hmm... the text you quote above relates to elpa.gnu.org scripts and > I don't see how it "ties into so many places in Emacs". What am > I missing. 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 ny pegging it after that other text. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds