Hi Eric and Achim, Eric Schulte <eric.schu...@gmx.com> writes:
> Achim Gratz <strom...@nexgo.de> writes: > >> Bastien writes: >>> I'm afraid the only recommendation here is to try to stick to one >>> installation method -- or to reinstall a fresh package/repo with a >>> fresh contrib/lisp/ *after* any ELPA upgrade. >> >> Well, we could make an ELPA package that includes contrib. It just >> can't be distributed via GNU ELPA then. > > I second this option. > > Given that ELPA and contrib/ both serve as a sort of proving ground for > tools which do not yet have some combination of the stability, copyright > assignment, or widespread utility to be included in Emacs or either > Org-mode it seems natural to distribute the contrib directory through > ELPA. Are you both talking about the same thing? (I use ELPA* to denote other ELPA archives than GNU ELPA.) If this is about a org-*.tar ELPA* package containing both *core* and *contrib*, I disagree. If this is about a org-contrib*.tar ELPA* (or wherever), I agree. Hopefully we can define dependencies for packages living on different ELPA* serveurs -- can someone confirm this? > I think either of the following repositories would make excellent homes. > > http://tromey.com/elpa/ > http://marmalade-repo.org/packages/ We don't have to chose, right? As long as one of them make it available, I'm fine. > Also, somewhat selfishly, I'd like to distribute my org-ehtml tool as an > ELPA package, but I can't until some of the functionality in contrib/ > can be installed through ELPA. Sure. If we are sure we can have a org-contrib in ELPA* that knows what org it should rely on GNU ELPA, then let's go ahead with such package. -- Bastien
