[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45435: Additional libraries required by transient and magit manuals
From: |
Stefan Monnier |
Subject: |
bug#45435: Additional libraries required by transient and magit manuals |
Date: |
Sun, 27 Dec 2020 10:58:15 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
>> So maybe rather than look for the solution by re-using the code we
>> already have lying around, we should "manually" add the handful of extra
>> packages to the builder's `~/.emacs.d/elpa` ?
>> The downside would be that it requires a manual step from someone with
>> access to `elpa.gnu.org`.
> That's what I had in mind and if it were you who kept that up-to-date,
> as opposed to some fsf admin, then that could work.
I'd most likely be the one keeping it up-to-date (the fsf admins have
better things to do than try and understand what we've setup inside the
VM ;-).
And yes, that would work but I'd rather not be so "indispensable".
Also it'd make it yet harder to approximate on your own machine what
happens on `elpa.gnu.org`.
>> Or maybe we could keep the contents of that
>> `~/.emacs.d/elpa` in a separate branch/directory and just make it
>> available to `:make` targets, so anyone with write access to the Git
>> repository can add (installed) packages in there.
> That is probably the better approach.
Yes, the more I think about it, the more I'm convinced that it's
obviously superior.
> Would you want check a copy of these libraries into the "main" branch?
I'm thinking of keeping it in a separate branch that can be shared
between `elpa.git` and `nongnu.git`.
> Maybe that branch should be renamed to "admin/elpa-admin" and other
> admin tools could use "admin/<name>" as well. Gnu elpa would end up
> with two identical branches for "ox-texinfo+": "externals/ox-texinfo+"
> and "admin/ox-texinfo+", nongnu elpa however would only feature the
> latter.
I'm rather thinking that the new branch would keep the equivalent of
`~/.emacs.d/elpa`, i.e. code that's in an "installed" state, e.g.
byte compiled, so not "two identical branches".
Stefan