Re: GNU ELPA and package.el

[Achim Gratz <Stromeko@nexgo.de>]

Stefan Monnier writes:
> 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.

As I said, I'll happily make an exception for ELPA as long as it's
hobbled to not allow a proper build and provide any number of extra
pre-generated files that make up for the difference.  What I do not want
to do (Org maintainer override is possible) is to alter files from their
state in orgmode.git (i.e. if you delete the pre-generated files the
result should be identical to a checkout from orgmode.git).

> What alternative do you suggest?

Either use one of the generated files (via a suitable naming convention)
as before, or take information from either/or tags and notes?

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

I no longer have the test scaffolding in place that allowed me to check
for this across a number of Emacs versions.  IIRC, the changes back then
addressed only that part of the problem that was immediate (i.e. the
package would either fail to compile or activate).

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

What I'm trying to say is that users might easily find themselves in the
situation that requires them to ignore part of their system installation
(which they can't do anything about because somebody else provides it).
While it is an unlikely case, I think it should still be possible.

> 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 order of all package directories provides a hierarchy already and in
most cases the highest rung should provide the definite information.
That part is mostly working already, I think.  The missing part is
masking single packages at any point in the hierarchy without requiring
the user to have write access to those directories.

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

s/delete/mask/

Does that make more sense now?  I'd be happy if you find a better word
for it.

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

No I don't, life's too short for that.  Anyway, as you say, lets move
things along a bit.

So, let's say the system has a package "Foo" installed and the user
wants to install and use an older version of that.  Another useful case
is to pretend the builtin package "Bar" wasn't there, lets say for
testing purposes (or top prevent problems on upgrading to a much newer
version in the user or system space).


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables