|
From: | Nic Ferrier |
Subject: | Re: package and testing rant (was Re: package.el, auto-installation, and auto-removal) |
Date: | Tue, 11 Nov 2014 11:41:16 +0000 |
Stefan Monnier <address@hidden> writes: > IIUC by "ELPA" above I guess you mean GNU ELPA (since "ELPA and MELPA" > would otherwise combine with "and" two things of different nature). > >> The multi-packages users load in their emacs are tars. But the packages >> that are checked in to ELPA are directories of files. > ^^^^^^^^^^^^^^^^^^ > So I think here you mean elpa.git (part of the greater GNU ELPA). Excellent clarification. That's what I mean in this instance. > Indeed. Note that for all packages (even single-file packages) there > are yet more build steps elsewhere: > - the creation of the <foo>-autoloads.el. > - the creation of the *.elc files. No. Those are not build steps. Those are installation steps. The package artifacts (the things delivered to end users) do NOT have auto-loads files or elc files in them. If they do they shouldn't because that's what Emacs package.el does when it installs them. It should go: build -> release -> install elpa.git and MELPA are promoting: release -> (build) -> install I don't think it's bad that MELPA promotes that. That's their business. But I do think it matters that elpa.git works that way. > Note that there is a fair bit a pressure to *add* rather than remove > magic steps (the first candidate in the list is to build the *.info > files from the *.texi files). I agree. If the build was clearly separated this pressure would move away into the build tools. >> And I am really starting to think we need better testing. 24.4 looked >> like a slog to release and it still has many bugs. > > FWIW, I haven't heard of any case where the issues you're pointing out > have resulted in actual problems. The only real reliability problem > I've heard about linked to ELPA packages is the issue of > compiling/installing a package when an older version is > already installed. Ok... I'm not sure I've come across an elpa.git package that has bugs because it wasn't tested. But then I don't use many right now. But my point is we agree (don't we?) that moving stuff into elpa.git from core is broadly right and I want to encourage a testing culture. Why do we want to move things into elpa.git? because we can fix bugs and add features quicker. Nic
[Prev in Thread] | Current Thread | [Next in Thread] |