GNU bug report logs -
#45435
Additional libraries required by transient and magit manuals
Previous Next
Full log
View this message in rfc822 format
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 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.
> 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.
Would you want check a copy of these libraries into the "main" branch?
We do that for "package-build.el" in the Melpa repository like so:
pull-package-build:
git subtree pull --squash -P package-build package-build master
I am not really a fan of that approach but it has the benefit that it is
robust.
Alternatively you could generalize the code that makes "elpa-admin.el"
available. "./admin" could then serve a similar purpose as "./package",
i.e. "./admin/elpa-admin" would become the worktree that checks out the
"elpa-admin" branch.
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.
Jonas
This bug report was last modified 4 years and 225 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.