From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: CVS is the `released version' Date: Sat, 02 Jun 2007 21:23:59 -0600 Message-ID: References: <86646mjvxp.fsf@lola.quinscape.zz> <2cd46e7f0705251413y975af0bwbd7c6709814fd915@mail.gmail.com> Reply-To: tromey@redhat.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1180842345 22050 80.91.229.12 (3 Jun 2007 03:45:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 3 Jun 2007 03:45:45 +0000 (UTC) Cc: emacs-devel@gnu.org, JD Smith To: "Ken Manheimer" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 03 05:45:43 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Huh2B-0007Ql-1A for ged-emacs-devel@m.gmane.org; Sun, 03 Jun 2007 05:45:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Huh2A-0005Lr-IT for ged-emacs-devel@m.gmane.org; Sat, 02 Jun 2007 23:45:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Huh25-0005KJ-5x for emacs-devel@gnu.org; Sat, 02 Jun 2007 23:45:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Huh24-0005K7-IW for emacs-devel@gnu.org; Sat, 02 Jun 2007 23:45:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Huh24-0005K4-Fb for emacs-devel@gnu.org; Sat, 02 Jun 2007 23:45:32 -0400 Original-Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Huh24-0001Cv-11 for emacs-devel@gnu.org; Sat, 02 Jun 2007 23:45:32 -0400 Original-Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l533jHND003581; Sat, 2 Jun 2007 23:45:18 -0400 Original-Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l533jHsf029937; Sat, 2 Jun 2007 23:45:17 -0400 Original-Received: from opsy.redhat.com (ton.toronto.redhat.com [172.16.14.15]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l533jFxG016841; Sat, 2 Jun 2007 23:45:16 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 39B27888393; Sat, 2 Jun 2007 21:23:59 -0600 (MDT) X-Attribution: Tom In-Reply-To: <2cd46e7f0705251413y975af0bwbd7c6709814fd915@mail.gmail.com> (Ken Manheimer's message of "Fri\, 25 May 2007 17\:13\:47 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.990 (gnu/linux) X-detected-kernel: Linux 2.6, seldom 2.4 (older, 4) 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: news.gmane.org gmane.emacs.devel:72095 Archived-At: A few belated responses to this thread, all in one message. I'll try to lay out some of my thinking behind package.el. Ken> (1) we are talking about enabling package developers and users to update Ken> the packages they use incrementally within a major emacs release, Ken> (2) without burdening emacs maintainers with change management chaos, Ken> and package.el came from a few ideas. The obvious one was to replace the ELL/Wiki/Ohio State Archive with something more machine-friendly (and thus simpler to make user-friendly). However I also wanted to be able to install a package (e.g., ERC) that was later pulled into Emacs; upgrade Emacs; and have my old, personal ERC install not be used any more. I've run into this situation any number of times in the past, and with the long Emacs release cycle and the many packages that exist now, it seemed a bit more important. This second idea basically works. It would work better with a bit of assistance from Emacs -- say a way to auto-compute the default value for `package-alist' at build time. Ken> (3) without reducing the incentive for package developers to assign Ken> copyright to the fsf. I don't know how to accomplish this to RMS' satisfaction. But perhaps some of the infrastructure from package.el can still end up in Emacs. Ken> (2) is the tricky bit. the situation would be simplest if the Ken> update system is contrived to only allow the entire collection of Ken> packages to be updated at as a whole. There are some theoretical problems here but I was planning to address them from the "active maintenance" point of view -- i.e., the ELPA maintainers would simply ensure, somehow, that the archive is internally consistent. This is related to... Lennart> I think this touches the most important point of a package Lennart> system. There must be something that can assure that the Lennart> package to download fits on the users system. I didn't want to try to deal with this in its full hairiness, but package.el at least solves part of the problem, namely by letting packages require minimum versions of other packages (including the special package "emacs"). Lennart> So please, do not add a package system that can only handle Lennart> single files and not their interdependencies. package.el handles both `single' and `tar' packages, and either type can have dependencies. Which is related to... Dhruva> Is it feasible/practical to have a keyword in the comment area Dhruva> of the file "providing" the package with list of depedencies Dhruva> and their locations? package.el doesn't deal with locations -- it assumes a single location. I am not a fan of the location-per-package approach, because I think a lesson from ELL is that locations often die. However, package.el does handle requirements, even for `single' packages, by defining a new "Package-Requires" header comment. E.g., a .el file that requires Emacs 22 could have: ;; Package-Requires: ((emacs "22.0")) Offhand I don't think anything currently in ELPA does this. But then, I haven't put much effort into trying to upload the bigger things out there. Tom