From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: GNU ELPA and package.el
Date: Sun, 07 Apr 2019 10:07:46 -0400 [thread overview]
Message-ID: <jwv5zrpdio6.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: 87mul2p9m0.fsf@Rainer.invalid
> 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
next prev parent reply other threads:[~2019-04-07 14:07 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-19 13:24 GNU ELPA package for CC-mode Stefan Monnier
2018-08-19 20:49 ` Alan Mackenzie
2018-08-19 23:45 ` Stefan Monnier
2018-08-20 8:24 ` Jostein Kjønigsen
2018-08-20 14:06 ` Stefan Monnier
2018-08-20 17:58 ` Jostein Kjønigsen
2018-08-21 13:30 ` Stefan Monnier
2018-08-21 16:20 ` Alan Mackenzie
2018-08-23 5:25 ` Stefan Monnier
2018-08-23 21:34 ` Alan Mackenzie
2018-08-23 22:17 ` Stefan Monnier
2018-08-24 8:43 ` Eli Zaretskii
2018-08-24 11:56 ` Michael Albinus
2018-08-24 22:21 ` Stefan Monnier
2018-08-25 8:43 ` Tramp as ELPA package (was: GNU ELPA package for CC-mode) Michael Albinus
2018-08-25 18:04 ` Tramp as ELPA package Stefan Monnier
2018-08-25 21:04 ` Stefan Monnier
2018-08-26 6:39 ` Andreas Schwab
2018-08-26 10:48 ` Michael Albinus
2018-08-26 11:09 ` Michael Albinus
2018-08-26 15:21 ` Stefan Monnier
2018-08-26 18:04 ` Michael Albinus
2018-08-26 18:27 ` Eli Zaretskii
2018-08-26 18:34 ` Michael Albinus
2018-08-26 19:03 ` Eli Zaretskii
2018-08-27 7:12 ` Michael Albinus
2018-08-27 13:33 ` Stefan Monnier
2018-08-27 13:41 ` Michael Albinus
2018-08-27 13:44 ` Stefan Monnier
2018-08-27 15:22 ` Michael Albinus
2018-08-27 15:09 ` Eli Zaretskii
2018-08-27 15:21 ` Michael Albinus
2018-08-26 15:30 ` Tom Tromey
2018-08-26 16:26 ` Stefan Monnier
2018-08-26 17:46 ` Michael Albinus
2019-04-04 12:41 ` Michael Albinus
2019-04-04 15:48 ` Stefan Monnier
2019-04-04 16:07 ` Michael Albinus
2019-04-05 14:43 ` Michael Albinus
2019-04-05 15:07 ` Dmitry Gutov
2019-04-05 16:19 ` Michael Albinus
2019-04-16 7:53 ` Steinar Bang
2019-04-05 18:14 ` Stephen Leake
2019-04-05 18:20 ` Stephen Leake
2019-04-05 22:18 ` Michael Albinus
2019-04-07 0:17 ` Stephen Leake
2019-04-07 7:41 ` Michael Albinus
2019-04-06 12:42 ` Stefan Monnier
2019-04-08 12:37 ` Michael Albinus
2019-04-08 13:07 ` Stefan Monnier
2019-04-08 13:31 ` Michael Albinus
2019-04-08 16:43 ` Stefan Monnier
2019-05-20 13:05 ` Michael Albinus
2019-06-30 19:20 ` Michael Albinus
2019-04-05 18:55 ` Achim Gratz
2019-04-06 22:25 ` GNU ELPA and package.el (was: Tramp as ELPA package) Stefan Monnier
2019-04-07 7:17 ` GNU ELPA and package.el Achim Gratz
2019-04-07 14:07 ` Stefan Monnier [this message]
2019-04-07 17:37 ` Achim Gratz
2019-04-07 20:31 ` Stefan Monnier
2019-04-08 17:55 ` Achim Gratz
2019-04-08 19:01 ` Stefan Monnier
2019-04-08 20:24 ` Achim Gratz
2019-04-09 1:39 ` Stefan Monnier
2018-08-25 19:15 ` GNU ELPA package for CC-mode Clément Pit-Claudel
2018-08-25 20:17 ` Stefan Monnier
2018-08-25 21:17 ` Tom Tromey
2018-08-25 23:28 ` Kyle Andrews
2018-08-24 15:48 ` Stefan Monnier
2018-08-24 19:21 ` Eli Zaretskii
2018-08-24 22:17 ` Stefan Monnier
2018-08-25 7:02 ` Eli Zaretskii
2018-08-25 8:51 ` Alan Mackenzie
2018-08-25 10:15 ` Michael Albinus
2018-08-25 18:07 ` Stefan Monnier
2018-08-25 18:27 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv5zrpdio6.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.