On Fri, Jul 10, 2015 at 8:47 AM, Alex Kost <alez...@gmail.com> wrote: > Federico Beffa (2015-07-09 23:41 +0300) wrote: > >> On Thu, Jul 9, 2015 at 10:51 AM, Alex Kost <alez...@gmail.com> wrote: >>> Federico Beffa (2015-07-08 23:22 +0300) wrote: >>> >>>> On Tue, Jul 7, 2015 at 6:58 PM, Alex Kost <alez...@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