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 10:07:46 -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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="100340"; 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 16:09:36 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 1hD8UK-000Q0s-BL for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2019 16:09:36 +0200 Original-Received: from localhost ([127.0.0.1]:39782 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hD8UI-00015Z-Ur for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2019 10:09:34 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hD8Sk-0000bg-CD for emacs-devel@gnu.org; Sun, 07 Apr 2019 10:07:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hD8Sj-0007J0-C0 for emacs-devel@gnu.org; Sun, 07 Apr 2019 10:07:58 -0400 Original-Received: from [195.159.176.226] (port=40752 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hD8Sj-0007CQ-0T for emacs-devel@gnu.org; Sun, 07 Apr 2019 10:07:57 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hD8Sh-000OBk-Dy for emacs-devel@gnu.org; Sun, 07 Apr 2019 16:07:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:JbjSfb/NO4tEmm8V//jtO/V88pk= 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:235069 Archived-At: > So the only thing you care about is that you don't want to deal with the > tar file? Pretty much, yes (there's also the use of org-pkg.el rather than headers in org.el to specify the package version). >>> The other unsolved problem is that anything that gets built in to Emacs >>> releases still can't be later cleanly updated as a package because none >>> of the "built-in packages" are actually packages in the ELPA sense. >> I don't know what problem you're thinking of. >> You can definitely upgrade Org, python.el, and several others. >> I can imagine scenarios where it can partly break, but most of them seem >> contrived to me, so if you know of practical problems, please let >> me know. > > The problem auf autoloads not being able to get redefined in a running > instance of Emacs. Autoload do get redefined by subsequent `autoload`s. Was there a bug report for it? > 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? > 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. - prefer older user-installed package over newer system-wide package. This is likely also unusual, but definitely possible and legitimate. 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? >>>> This is what AUCTeX does, basically (where the files that would >>>> ideally be auto-generated during packaging are instead stored in the >>>> elpa.git repository after making them manually). >>> That is a mistake and should not be forced on anyone. >> I don't consider it a feature, but other than complaints, I haven't >> gotten much help in trying to improve the situation. > 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. Stefan