Re: Org merging [was Re: next pretest]

[Achim Gratz <Stromeko@nexgo.de>]

Stefan Monnier writes:
>> As someone essentially unqualified to comment, I'll keep this short: how
>> about checking for an "elpa" target to make? Run it if it exists, do
>> nothing if it doesn't.
>
> Of course, but that's not the issue.  The problems are rather:
> - The machine on which the GNU ELPA archive is built is a small virtual
>   machine, with fairly few software packages installed, currently.
>   We can add more, of course.

Org needs these programs for bootstrapping a release into a
package (the GNU versions if there are alternatives):

 emacs makeinfo make rm ln install tar echo find git

The use of make implies sh (any POSIXy shell will do) and makeinfo and
git have (extensive) further dependencies.  For the reference card and
manual you'd need PDFLaTeX as well.

> - Since the GNU ELPA archive is auto-built nightly from the `elpa'
>   branch and (inevitably) many people have write access to the `elpa'
>   branch, there's a security issue if we run just arbitrary code from
>   the `elpa' branch.

Those builds should run in their own VM obviously, but that may not be
easily set up.  Bouncing a work tree over Git with the info and autoload
files pre-built really isn't all that different than just handing you
the tarball to distribute, so I think that'd be a toss-up.  You just
have that build done on orgmode.org instead of elpa.gnu.org in this
case.


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

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada