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

[Alex Kost <alezost@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

Federico Beffa (2015-07-09 23:41 +0300) wrote:

> On Thu, Jul 9, 2015 at 10:51 AM, Alex Kost <alezost@gmail.com> wrote:
>> Federico Beffa (2015-07-08 23:22 +0300) wrote:
>>
>>> On Tue, Jul 7, 2015 at 6:58 PM, Alex Kost <alezost@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.
>
> One difference that I noticed in the tar files is that tar coming from
> elpa archives always include the .info file, while the upstream ones
> do not always do so. I've not investigated further differences.

I think that the upstream never include (at least they shouldn't)
".info" files.  So perhaps it would be good to add a phase for building
info manual if there are ".texi" files and no ".info".

> While often the READMEs are not very usefull, sometimes they are.

But do people look at ~/.guix-profile/share/emacs/site-lisp/guix.d/foo
directory to find README and other useful non-elisp files?

> Therefore I do not like the idea of removing them, nor anything else
> provided by the package. It's upstream who should decide what's
> relevant. With the use of 'guix.d' there will be no name clashes. Did
> you happen to see the following thread?
>
> https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00392.html

Yes, I read it, but when you say «provided by the package» and «It's
upstream who should decide», you are talking about the packages imported
from (m)elpa, not the upstream itself.  Since melpa is unusable (due to
a hash problem), we'll have to use the direct upstream releases, which
are not stripped from ".gitignore" and other unrelated files.  So all
these files will move into "…/.guix.d/package" dir.

As an example, try the following variant of "emacs-mmm-mode" package:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacs-mmm-mode.scm --]
[-- Type: text/x-scheme, Size: 727 bytes --]

(define-public emacs-mmm-mode
  (package
    (name "emacs-mmm-mode")
    (version "0.5.4")
    (source
     (origin
       (method url-fetch)
       (uri (string-append
             "https://github.com/purcell/mmm-mode/archive/"
             version ".tar.gz"))
       (file-name (string-append name "-" version ".tar.gz"))
       (sha256
        (base32
         "10kwslnflbjqm62wkrq420crqzdqalzfflp9pqk1i12zm6dm4mfv"))))
    (build-system emacs-build-system)
    (home-page "https://github.com/purcell/mmm-mode")
    (synopsis
     "Allow multiple major modes in an Emacs buffer")
    (description
     "MMM Mode is a minor mode that allows multiple major modes to coexist in a
single buffer.")
    (license license:gpl3+)))

[-- Attachment #3: Type: text/plain, Size: 898 bytes --]


As you can see, there are many odd files in the
"…/share/emacs/site-lisp/guix.d/mmm-mode-0.5.4" directory.

So I suggest to add a phase for deleting non-".el[c]" files from the
".guix.d/package" directory.

And just in case: I have nothing against GNU ELPA repository (especially
taking into account that it is the only "home" for some packages).  I'm
against melpa and melpa-stable, because:

- Why should we rely on a third-party server that do something with the
  upstream files to produce a final tarball?

- MELPA(-stable) is not usable anyway, because the tarballs of the same
  version are updated all the time, so the hash is being permanently
  changed.

However, if a package from ELPA has a real upstream release that can be
used with "gnu-build-system" (e.g., emms, auctex, mmm-mode), I think we
should prefer it instead of importing it from ELPA.

-- 
Alex