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

[Federico Beffa <beffa@ieee.org>]

On Fri, Jul 10, 2015 at 8:47 AM, Alex Kost <alezost@gmail.com> wrote:
> 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?

My guess is that people using the Emacs packaging system (and by
extension Emacs users) do, because that's very similar to the Emacs'
native packaging strategy.

>
>> 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:
>
>
>
> 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?

Well, that's just a necessary step to make Emacs 'package.el' work properly.

>
> - 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.

Nowadays many Emacs packages recommend to use Emacs' packaging system
as the preferred method of installation. See e.g.
https://github.com/purcell/mmm-mode

However, the hash problem with packages from melpa appears to be a show stopper.

Fede