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

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

> I am guessing that [non]gnu elpa currently use the version of org that
> comes with Emacs.

Indeed, more specifically with the Emacs distributed in Debian stable,
i.e. Emacs-26 currently.

> Please consider making "org/contrib/lisp/" and "ox-texinfo+.el"
> available to the elpas.

IIUC Bastien is working on (or planning to soon work on) adding org-contrib
to NonGNU ELPA.  As for `ox-texinfo+.el` (or any other package you
fancy), feel free to add them to `elpa.git` or `nongnu.git` (depending
on their copyright paperwork status, mostly).

But the main point you raise is the use of extra packages when building
(Non)GNU ELPA packages, such as for the needs of building the
Info manual.

There are mostly two issues:

1- The philosophical issue of relying on packages which we don't distribute.
   I think we should try and only use ELisp packages which we
   distribute, either as part of Emacs or GNU ELPA or NonGNU ELPA.
   But this should be easy to fix: just add the package to
   (Non)GNU ELPA.

2- Making use of those extra packages while building your own (Non)GNU
   ELPA package.  This is a technical issue and I'm not completely sure
   how best to solve it.

I think point 2 is the only relevant problem here, so I suggest we focus
on this in the bug#45435.

Currently, when building a GNU ELPA package, the `:make` rule has read
access to the whole of `elpa.git`, and similarly while building a NonGNU
ELPA package, the `:make` rule has read access to the whole of
`nongnu.git`.

There are several problem, tho:
1- GNU ELPA Packages aren't readable while building NonGNU ELPA
   packages, and vice-versa.
2- While there is read access to the source code of other packages,
   these aren't "prepared" to be activated (as by
   `package-activate-all`), e.g. their [PKG]-pkg.el and more importantly
   [PKG]-autoloads.el files haven't been built (and they haven't been
   byte-compiled either).
3- Of course, the code available is (usually) that of the head of their
   respective branch, which may be in a temporarily broken state.

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

Hmm...


        Stefan