From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Emacs Package Management Date: Mon, 11 Aug 2008 21:10:28 -0700 Message-ID: <48A10D34.5050601@emf.net> References: <485b0c380808011427n4d3144eey3f8daf3abac83bf4@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1218511275 32162 80.91.229.12 (12 Aug 2008 03:21:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Aug 2008 03:21:15 +0000 (UTC) Cc: Stephen Eilert , emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 12 05:22:06 2008 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 1KSkSS-0000e8-1H for ged-emacs-devel@m.gmane.org; Tue, 12 Aug 2008 05:22:04 +0200 Original-Received: from localhost ([127.0.0.1]:47693 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSkRV-0004gO-LK for ged-emacs-devel@m.gmane.org; Mon, 11 Aug 2008 23:21:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KSkRQ-0004dp-9n for emacs-devel@gnu.org; Mon, 11 Aug 2008 23:21:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KSkRO-0004bx-Qq for emacs-devel@gnu.org; Mon, 11 Aug 2008 23:20:59 -0400 Original-Received: from [199.232.76.173] (port=41357 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSkRO-0004bp-Mx for emacs-devel@gnu.org; Mon, 11 Aug 2008 23:20:58 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:41601) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1KSkRO-0003sF-KX for emacs-devel@gnu.org; Mon, 11 Aug 2008 23:20:58 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.75.7] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 36703088; Mon, 11 Aug 2008 20:20:44 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: X-detected-kernel: by monty-python.gnu.org: 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:102310 Archived-At: Tom Tromey wrote: > There was a discussion a while ago on this list. RMS wanted to > restrict the available packages to those which had been assigned to > the FSF, but I did not agree with that. > Please consider making the package system such that packages are signed and users consciously pick and choose among authorities (i.e., which package signatures to trust). To an extent, that makes the problem harder: a key management system has to be part of the package system if "average" users are expected to be able to use it. On the other hand, it creates an economic market -- especially if you keep that in mind while designing the package system. That is, a new possible commercial service (entirely free-software friendly) is to let people subscribe to a source of trusted emacs packages. Providers of this service can differentiate and compete in lots of ways. I think a worthy goal is to design a package system that helps such a market flourish. Firefox has a feature that illustrates a nice and relevant paradigm: It frequently "calls home" to find out if a new upgrade has been published and then automates the process of installing upgrades. Emacs and the possible marketplace for emacs package providers could benefit from a similar infrastructure. It is hard to get right, of course: very easy to introduce vulnerabilities through design or coding mistakes. Nevertheless, if it *is* gotten right, it helps to create that marketplace. In other threads about DOS and Windows support, people were talking about the ideal of never having to earn a living in the proprietary software world. It seems to me that the most direct way to make that possible is to collectively concentrate on software systems that create markets for free software developer talent (by virtue of the architecture of those systems). Package systems are exactly the right place to hack markets to create free software jobs. RHAT and Canonical both discovered this a ways back. An industry standard here, a really solid one, would crank up competition and generally "lubricate" the free software economy (by lowering the barrier to entering the market as a package-by-subscription provider while still preserving the opportunity for package providers to differentiate and add value between upstream and the user). It is not something that those companies are likely to be eager for until it becomes inevitable. Therefore it might well be a good strategic investment for volunteers. One final technical note: In designing the package system it is desirable not only to allow competing package provider services, but also (reflecting the reality of software development) to afford composing providers into "pipelines". That is, the package system should model the concept of an upstream developer giving code to downstream service providers who in turn give code (possibly patched) to end users. An end-user package download transaction should be able to report the "heritage" of the package to that level. The reason for this is to create the possibility of a market for "royalties" paid to upstream developers -- that is, to create a funding pipeline for free software R&D. -t