From mboxrd@z Thu Jan 1 00:00:00 1970 From: Federico Beffa Subject: Re: [PATCH 3/5] build: Add 'emacs-build-system' Date: Fri, 10 Jul 2015 09:43:51 +0200 Message-ID: References: <87pp43j45o.fsf@gmail.com> <87oajlemsl.fsf@gmail.com> <87pp401pb5.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDSyQ-0000SO-CV for guix-devel@gnu.org; Fri, 10 Jul 2015 03:43:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDSyO-00008H-FM for guix-devel@gnu.org; Fri, 10 Jul 2015 03:43:54 -0400 Received: from mail-ig0-x22f.google.com ([2607:f8b0:4001:c05::22f]:32856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDSyO-00008A-8D for guix-devel@gnu.org; Fri, 10 Jul 2015 03:43:52 -0400 Received: by iggp10 with SMTP id p10so30142953igg.0 for ; Fri, 10 Jul 2015 00:43:51 -0700 (PDT) In-Reply-To: <87pp401pb5.fsf@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Alex Kost Cc: Guix-devel On Fri, Jul 10, 2015 at 8:47 AM, Alex Kost wrote: > Federico Beffa (2015-07-09 23:41 +0300) wrote: > >> On Thu, Jul 9, 2015 at 10:51 AM, Alex Kost wrote: >>> Federico Beffa (2015-07-08 23:22 +0300) wrote: >>> >>>> On Tue, Jul 7, 2015 at 6:58 PM, Alex Kost wrote: >>>>> A side note: I think generally it would be preferable to use an upstr= eam >>>>> 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/=E2=80=A6-foo-0.1/share/emacs/site-lisp/guix.d/foo-0.1/ dire= ctory. >> >> 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 =C2=ABprovided by the package=C2=BB and = =C2=ABIt's > upstream who should decide=C2=BB, you are talking about the packages impo= rted > 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 "=E2=80=A6/.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 > "=E2=80=A6/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 sto= pper. Fede