guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 3/5] build: Add 'emacs-build-system'


From: Alex Kost
Subject: Re: [PATCH 3/5] build: Add 'emacs-build-system'
Date: Thu, 09 Jul 2015 11:51:38 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Federico Beffa (2015-07-08 23:22 +0300) wrote:

> On Tue, Jul 7, 2015 at 6:58 PM, Alex Kost <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]