Re: GNU ELPA and package.el

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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