Re: GNU ELPA and package.el

[Stefan Monnier]

>> 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.

elpa.gnu.org generates the packages from the various branches of elpa.git.
So I'm not sure where it should get its version info if not from version
controlled files.
What alternative do you suggest?

>> 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.

Hmm... IIRC since that discussion package.el was changed to try and
address those problems (starting with
c13baa10d55ec863d3ceaea48c6b2959ece98198, on Dec 2014).

So if there are remaining issues, could you open a new bug report?

>> 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.

Not sure in which way that's related to the issue of system-wide
ELPA packages.

>> - prefer older user-installed package over newer system-wide package.
>>   This is likely also unusual, but definitely possible and legitimate.
> Yes.

One way we could do this is to always prefer the user-installed version
over the system-wide one (tho, this will inevitably be somewhat brittle
since we actually don't truly know which directories are "user" and
which are "system", we can only approximate it e.g. by checking if we
have write access or by declaring that package-user-dir is the only
user directory and all others are system-wide).

>>> 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.

I still don't know what you mean by "delete" here.

> 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 by
> pegging it after that other text.

I sense that you're venting a lot of frustration, but it's difficult to
move forward without clear and concrete cases to discuss.


        Stefan