Federico Beffa (2015-07-08 23:22 +0300) wrote: > On Tue, Jul 7, 2015 at 6:58 PM, Alex Kost <alez...@gmail.com> wrote: >> 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 > > I believe that such information is not available from ELPA archives. > Therefore the ELPA importer has no way to do this. But, obviously, > manual modification is possible. (By the way, the tar files are > similar but not identical.)
Surely, I didn't mean that it's a task for the elpa importer. I'm totally for the manual modification to use an upstream release, not the melpa(-stable) one. By "the tar files are similar" do you mean that MELPA usually leaves only elisp files in the tarballs? I think since it's a common practice to put elisp files in the root directory of the repo, we should add a phase to the emacs build system to remove non-elisp files (like .gitignore or README) from the final /gnu/store/…-foo-0.1/share/emacs/site-lisp/guix.d/foo-0.1/ directory. >> 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. > > Currently this can be handled, as in many packages using other build > systems, by custom phases. But handling of this type of packages would > definitely be useful. Unfortunately, in the near future, I will not > have time to spend on this. I've pushed the code as reviewed on the ML > today. If you are interested, feel free to improve/extend it. Thanks for the proposal :-) -- Alex