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: Fri, 18 May 2007 17:31:43 -0600 Message-ID: References: <2cd46e7f0705101124r72000f78xdf05d18ca815ca57@mail.gmail.com> <17991.47259.210100.801472@localhost.localdomain> 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 1179532275 9097 80.91.229.12 (18 May 2007 23:51:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 18 May 2007 23:51:15 +0000 (UTC) Cc: joakim@verona.se, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 19 01:51:13 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 1HpCE5-0008Mi-3e for ged-emacs-devel@m.gmane.org; Sat, 19 May 2007 01:51:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HpCE4-00020v-Ld for ged-emacs-devel@m.gmane.org; Fri, 18 May 2007 19:51:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HpCE1-00020q-Bm for emacs-devel@gnu.org; Fri, 18 May 2007 19:51:09 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HpCDy-00020e-Tw for emacs-devel@gnu.org; Fri, 18 May 2007 19:51:08 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HpCDy-00020b-Nq for emacs-devel@gnu.org; Fri, 18 May 2007 19:51:06 -0400 Original-Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HpCDx-0002fp-Ko; Fri, 18 May 2007 19:51:05 -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 l4INoxUK009121; Fri, 18 May 2007 19:50:59 -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 l4INowQ2030457; Fri, 18 May 2007 19:50:59 -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 l4INovUV002925; Fri, 18 May 2007 19:50:57 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 16E2937838F; Fri, 18 May 2007 17:31:43 -0600 (MDT) X-Attribution: Tom In-Reply-To: (Richard Stallman's message of "Fri\, 18 May 2007 19\:10\:20 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (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:71359 Archived-At: >>>>> "rms" == Richard Stallman writes: rms> Maybe it is worth doing that, though calling it a "package rms> system" seems like hype. Perhaps we have different ideas about what this means. My use comes from the distro world, where it basically refers to the combination of "binary" downloads and dependency tracking. I'm not a real lisp programmer but I gather this has some other meaning in the lisp world...? rms> 1. It could reduce the incentive for people to assign copyright rms> on their code. Yeah, this is definitely to be preferred. I'm not comfortable requiring it, though, because there are very useful Emacs Lisp packages which, AIUI, will never be assigned to the FSF. rms> 2. It would mean that Emacs refers people very strongly to a site that rms> isn't run by the GNU Project. I don't know what their policies are. rms> But even if they are good, now, we have no way to assure that remains rms> so. Currently there is no "they", just me :). My current policy is that ELPA accepts anything that is free software. Of course we could have an official GNU ELPA and then also change package.el to support multiple repository URLs, so that users could point to some non-FSF repository. I wouldn't have a problem asking people to assign their code first, and only uploading to the other repository if they say no. > It also mandates a > couple file names, the main one being the .el file that holds the > "define-package" call. rms> Something like a "define-package" call is one of the things that makes rms> me dislike package systems. Can we avoid this? Why is it needed? It is only needed for multi-file packages. Essentially package.el needs 3 pieces of information about a package: its name, its version number, and its requirements. For a single-file package these are extracted from comments; package.el defines a new comment header ("Package-Requires") for requirements, but so far I think this is unused. For a multi-file package the problem is just knowing where to look to get this information. It seemed simplest to have the package maintainer provide it in a well-known place. For a single-file package the quux-pkg.el file is generated by package.el at install time. Tom