Re: GNU ELPA and package.el

[Achim Gratz <Stromeko@nexgo.de>]

Stefan Monnier writes:
> 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.  I'm fine with
generating extra files to help ELPA along, but not to alter existing
files from their version-controlled state.

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

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

See above, more of it was here on emacs.devel, around four years ago or
even a bit earlier.  The Gmane IDs unfortunately are useless now, I need
to dig into the archives to get you working links… here are three
mailing list threads:

http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00567.html
http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg00207.html
http://lists.gnu.org/archive/html/emacs-devel/2016-09/msg00425.html

[Btw, the search page in the mailing list archive has a bug: when you
try to change the search string or the sort order it will remove the
index being searched and doesn't find anything until you add it back
manually.]

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

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.

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

Yes.

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

More generally, being able to "delete" a package at any level (or making
it completely invisible) is immensely useful for testing.

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

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


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds