From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Phil Hagelberg Newsgroups: gmane.emacs.devel Subject: Re: Emacs Package Management Date: Mon, 28 Sep 2009 14:13:02 -0700 Message-ID: <87ab0eai3l.fsf@hagelb.org> References: <485b0c380808011427n4d3144eey3f8daf3abac83bf4@mail.gmail.com> <87ej589vku.fsf@hagelb.org> <485b0c380808050609y56042595l42a5bb05b34458f0@mail.gmail.com> <485b0c380909161536t331a71fdg1c45150c418b72b2@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1254172415 14121 80.91.229.12 (28 Sep 2009 21:13:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2009 21:13:35 +0000 (UTC) Cc: Tom Tromey , rms@gnu.org, Stephen Eilert , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 23:13:28 2009 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 1MsNX9-0007bK-5B for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2009 23:13:23 +0200 Original-Received: from localhost ([127.0.0.1]:52089 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsNX7-0007fU-Qu for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2009 17:13:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MsNX2-0007fD-SD for emacs-devel@gnu.org; Mon, 28 Sep 2009 17:13:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsNWx-0007ey-Ay for emacs-devel@gnu.org; Mon, 28 Sep 2009 17:13:15 -0400 Original-Received: from [199.232.76.173] (port=49466 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsNWx-0007ev-7R for emacs-devel@gnu.org; Mon, 28 Sep 2009 17:13:11 -0400 Original-Received: from caiajhbdcbef.dreamhost.com ([208.97.132.145]:52406 helo=homiemail-a18.g.dreamhost.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MsNWu-0001Wt-W5; Mon, 28 Sep 2009 17:13:09 -0400 Original-Received: from enigma (96-26-232-193.sea.clearwire-dns.net [96.26.232.193]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by homiemail-a18.g.dreamhost.com (Postfix) with ESMTPSA id 5322A250070; Mon, 28 Sep 2009 14:13:07 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Thu, 17 Sep 2009 09:43:43 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:115742 Archived-At: Stefan Monnier writes: > For the FSF-hosted repository of packages, I'd want all the packages > to be version controlled, so the "submit-package" would be nothing else > than "bzr commit" (but yes, some extra code would need to be written to > automatically build a tarball out of the newly committed code, ...). > >> Yes, this is something that package.el provides. One thing that would >> be nice is to have Emacs also advertise the packages it provides -- that > > Indeed, we'd of course want that, if/once we provide such > a package system. But that should be easy. It seems like though there are a few questions remaining about policies for submissions, there's a general consensus that Emacs should get a packaging system, probably based on package.el with some enhancements for submitting projects. I'd like to start brainstorming as to what this would look like. One way to do it would be to have every package register as a Savannah project, and have some kind of operation (probably implemented as an elisp function) that could produce the static files that package.el consumes and place them in a publicly accessible http-served directory. Making package releases correspond with VCS tags would simplify things, so with some kind of post-commit hooks Savannah could run this function whenever a tag is updated in the project. This would require very few changes to package.el. Writing such a function should not be difficult. The only question is how easy it would be to get Savannah to run it at the right time. Thoughts? -Phil