Federico Beffa (2015-07-07 10:21 +0300) wrote: > Alex Kost <alez...@gmail.com> writes: > >> Wouldn't it be better to name it "elpa-build-system" as that's what it >> is in my opinion, since it does not retrieve the source directly from >> upstream but from ELPA/MELPA/... "repositories" instead. > > The build system doesn't assume anything about the source location. >> >> I imagine there may appear another build system for simple emacs >> packages (that don't provide Makefile, etc.) that will compile elisp >> files, generate autoloads and so on. I think it will be a system that >> should be called "emacs-build-system". WDYT? > > That's what the proposed build system does. If it lacks some > functionality that you think is desirable, I think it is better to add > it here rather than adding another, almost identical, build system.
Ah, I'm very sorry, You are right; emacs build system and elpa importer were mixed in my head :-) A side note: I think generally it would be preferable to use an upstream release in the package recipe rather than to use a melpa(-stable) URL, i.e.: http://foo-upstream.org/foo-0.1.tar.gz instead of http://stable.melpa.org/packages/foo-0.1.tar Also along with the concern that melpa stores a tarball only for the latest package version I think I've found another problem that will happen with a package from any repository: there are many single-file packages and these ones are not put in tarballs. I mean the package in this case is just a simple elisp file, so the 'unpack' will fail. Look at <http://elpa.gnu.org/packages/rainbow-mode.html> for example: guix import elpa --archive=gnu rainbow-mode gives a package that fails on 'unpack' phase. -- Alex
