[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU ELPA and package.el
From: |
Stefan Monnier |
Subject: |
Re: GNU ELPA and package.el |
Date: |
Sun, 07 Apr 2019 10:07:46 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
> 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
- Re: Tramp as ELPA package, (continued)
- Re: Tramp as ELPA package, Stefan Monnier, 2019/04/06
- Re: Tramp as ELPA package, Michael Albinus, 2019/04/08
- Re: Tramp as ELPA package, Stefan Monnier, 2019/04/08
- Re: Tramp as ELPA package, Michael Albinus, 2019/04/08
- Re: Tramp as ELPA package, Stefan Monnier, 2019/04/08
Re: Tramp as ELPA package, Achim Gratz, 2019/04/05
- GNU ELPA and package.el (was: Tramp as ELPA package), Stefan Monnier, 2019/04/06
- Re: GNU ELPA and package.el, Achim Gratz, 2019/04/07
- Re: GNU ELPA and package.el,
Stefan Monnier <=
- Re: GNU ELPA and package.el, Achim Gratz, 2019/04/07
- Re: GNU ELPA and package.el, Stefan Monnier, 2019/04/07
- Re: GNU ELPA and package.el, Achim Gratz, 2019/04/08
- Re: GNU ELPA and package.el, Stefan Monnier, 2019/04/08
- Re: GNU ELPA and package.el, Achim Gratz, 2019/04/08
- Re: GNU ELPA and package.el, Stefan Monnier, 2019/04/08