From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: `make' written in elisp Date: Mon, 03 Jan 2005 00:22:31 +0100 Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1104708186 9865 80.91.229.6 (2 Jan 2005 23:23:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 Jan 2005 23:23:06 +0000 (UTC) Cc: emacs-devel@gnu.org, Stefan Monnier , schierlm@gmx.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 03 00:22:59 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ClF3q-0006fD-00 for ; Mon, 03 Jan 2005 00:22:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClFEy-0008NH-DL for ged-emacs-devel@m.gmane.org; Sun, 02 Jan 2005 18:34:28 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1ClFEi-0008Ms-Hp for emacs-devel@gnu.org; Sun, 02 Jan 2005 18:34:12 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1ClFEh-0008MA-QU for emacs-devel@gnu.org; Sun, 02 Jan 2005 18:34:12 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1ClFEh-0008Lv-NM for emacs-devel@gnu.org; Sun, 02 Jan 2005 18:34:11 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ClF3X-0006Bq-KJ for emacs-devel@gnu.org; Sun, 02 Jan 2005 18:22:39 -0500 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1ClExJ-0006sL-5Q; Sun, 02 Jan 2005 18:16:13 -0500 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Sun, 02 Jan 2005 11:06:22 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:31703 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31703 Richard Stallman writes: > A year after you posted it, I finally read the source code of install.el. > (I was too backlogged to read source code last January.) > > I found that it was extremely clean and appealing code. If a > package system for Emacs can mean something like this, I am in favor > of it. Judging from the comments, this installer might more or less get along at least with some XEmacs packages, as well as some other packages with a regular enough structure (AUCTeX has in the mean time gotten a new autoconf-based installer very similar to that of preview-latex, so the latest versions probably will not work with install.el). As far as I understand the XEmacs package system (at which I have taken a cursory glance at best), it consists of several parts: a) a directory layout. XEmacs packages have a standard way of placing Elisp, info, data and other files in a layout under the top package directory. In addition there are some standard file names for initializing of packages and installation. In short, this part of the package system is basically just file layout conventions relative to a package-specific top directory. We don't have any conventions for packages intended for Emacs as far as I can see. It certainly would not be bad to have something like that: if people make code for Emacs, and if we can agree on some layout that makes it easier for stuff to work out of the box, it certainly might be worthwhile to state some conventions. b) version management. Versions must basically be floats, higher versions correspond to later versions, are usually based on some CVS archive and not at all with actual package versions. Uh. c) a package manager that will download and upgrade packages. It might do so in user-specific and system-wide packages. d) central download archives that will provide all packages, updated by packagers (often different from the actual creators of software) on central servers. e) it does not offer AFAIR: dependencies and standard tests (for executables, directories and other stuff) that autoconf provides. A bit of framework for that might be nice for obliterating some necessities for installation. Even though installing MSYS is not particularly hard, it still seems to be a barrier for some people. I am not convinced about the value of the centralized server approach to package management from XEmacs: it does not seem to lend itself overly well to getting reasonably updated packages from third developers (who often have their own download areas from which they offer their stuff, and those would not normally be visible to the package manager that just looks at one server for all packages at one time IIUC). But I do think that we should try to offer some way of installing external Lisp code if one has acquired it as a zip or tar archive in some manner already. And in those respects where the directory structure and layout conventions of an XEmacs package would seem reasonable, there seems little point in inventing something else. Stefan, having met those problems when writing install.el already, would probably be a lot more qualified to comment on my impressions and on the versatility of the package layout he has been catering for. > I would suggest some small changes. [...] All of those certainly sound reasonable. In particular, I'd second having separate commands for installing system-wide and user-local packages. IIRC (I might well be mistaken), XEmacs automatically picked one or the other automatically, based on whether one had previous private packages, and that was less than great. In particular, I tend to install a CVS version of Emacs into its own tree (from my own user), and this means that I can, as a user, install packages into this Emacs' system tree. But that does not imply that I don't want to install some stuff also in my user-local tree (which would get shared by the regular Emacs as well). Having separate commands would appear to be beneficial. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum