From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Kost Subject: Re: [PATCH 3/5] build: Add 'emacs-build-system' Date: Fri, 10 Jul 2015 09:47:58 +0300 Message-ID: <87pp401pb5.fsf@gmail.com> References: <87pp43j45o.fsf@gmail.com> <87oajlemsl.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDS77-00072z-PP for guix-devel@gnu.org; Fri, 10 Jul 2015 02:48:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZDS74-0006O4-HP for guix-devel@gnu.org; Fri, 10 Jul 2015 02:48:49 -0400 Received: from mail-la0-f54.google.com ([209.85.215.54]:34856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZDS74-0006Nx-55 for guix-devel@gnu.org; Fri, 10 Jul 2015 02:48:46 -0400 Received: by labgy5 with SMTP id gy5so107443805lab.2 for ; Thu, 09 Jul 2015 23:47:59 -0700 (PDT) In-Reply-To: (Federico Beffa's message of "Thu, 9 Jul 2015 22:41:04 +0200") 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: Federico Beffa Cc: Guix-devel --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 upstre= am >>>> 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/ direc= tory. > > 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 =C2=ABprovided by the package=C2=BB and = =C2=ABIt's upstream who should decide=C2=BB, you are talking about the packages import= ed 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: --=-=-= Content-Type: text/x-scheme Content-Disposition: inline; filename=emacs-mmm-mode.scm (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+))) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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? - 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. --=20 Alex --=-=-=--