bug#45435: Additional libraries required by transient and magit manuals

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

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