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: Integrating package.el Date: Tue, 05 Jan 2010 12:14:14 -0700 Message-ID: References: <878wclke6j.fsf@lifelogs.com> <87k4w5lbyb.fsf_-_@lifelogs.com> <87zl50jv52.fsf@lifelogs.com> <87d41rn3wt.fsf_-_@hagelb.org> <87k4vxiwlj.fsf@lifelogs.com> <87aawsh7ou.fsf@lifelogs.com> Reply-To: Tom Tromey NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262718911 22276 80.91.229.12 (5 Jan 2010 19:15:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jan 2010 19:15:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 05 20:15:04 2010 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 1NSEru-0005fX-5B for ged-emacs-devel@m.gmane.org; Tue, 05 Jan 2010 20:15:02 +0100 Original-Received: from localhost ([127.0.0.1]:52087 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSEru-0005Em-HI for ged-emacs-devel@m.gmane.org; Tue, 05 Jan 2010 14:15:02 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSErG-00053q-Lx for emacs-devel@gnu.org; Tue, 05 Jan 2010 14:14:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSErC-00051D-OY for emacs-devel@gnu.org; Tue, 05 Jan 2010 14:14:22 -0500 Original-Received: from [199.232.76.173] (port=53417 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSErC-000512-Kk for emacs-devel@gnu.org; Tue, 05 Jan 2010 14:14:18 -0500 Original-Received: from mx1.redhat.com ([209.132.183.28]:39654) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NSErB-0006JX-HP for emacs-devel@gnu.org; Tue, 05 Jan 2010 14:14:18 -0500 Original-Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o05JEGKX014557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Jan 2010 14:14:16 -0500 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o05JEFnM018156; Tue, 5 Jan 2010 14:14:15 -0500 Original-Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o05JEE3s009048; Tue, 5 Jan 2010 14:14:14 -0500 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 3BEA13781CA; Tue, 5 Jan 2010 12:14:14 -0700 (MST) X-Attribution: Tom In-Reply-To: <87aawsh7ou.fsf@lifelogs.com> (Ted Zlatanov's message of "Tue, 05 Jan 2010 09:50:41 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:119457 Archived-At: >>>>> "Ted" == Ted Zlatanov writes: Tom> It also needs to be changed to be able to manage multiple install Tom> locations, if it is to be used to manage site-lisp. Ted> Good point, but do you mean multiple search locations for existing Ted> installs? I would expect a single install location, otherwise it gets Ted> complicated... Basically we need to handle 3 install locations: the Emacs install tree, the global site-lisp, and the user's install location. These only need to be handled during the activation step. When the user installs a new package, it should always go to his personal install location. Right now package.el handles the Emacs install tree in a hacky way and ignores site-lisp entirely. Ted> This has been a very Ted> common complaint about Gnus. Installing it is the easy part, since it Ted> comes with Emacs. Can package.el support that? I can't tell if this is Ted> the "activate" or the "load" stage (are they states or state Ted> transitions? English can be so ambiguous...) or something new; also it Ted> seems like this is something external to Gnus, a function of the ELPA Ted> wrapper (although it may be bundled within Gnus) rather than something Ted> Gnus will always run for new users. This is the major question I have Ted> before I propose this packaging on the Gnus mailing list. This would be a new thing. I agree with the other posters who recommend that this be done in Gnus, not as something related to package.el. Ted> I also want to know if you and Phil want to make Gnus your first Ted> Emacs-hosted package, or if there's going to be a ELPA clone of Gnus. FWIW, ELPA already includes some packages that are also included in Emacs. I maintain the necessary metadata for this by hand (and, I'm afraid, not very well at the moment due to lack of time -- I think I am missing some updates). Ted> I'd actually like both: the Emacs-hosted version is "Emacs-supported Ted> Gnus" while the ELPA versions are "bleeding-edge Gnus from CVS" and Ted> "latest Gnus release." The last one is usually but not always Ted> synchronized with the Emacs release; I'll need to ask the other Gnus Ted> developers what they think. At least two Gnus versions in package.el Ted> make sense in any case. package.el doesn't support this at the moment. Thanks for bringing this up, though. I think it is pretty important to flush out all these use cases. I can think of a couple solutions to this problem. One would be to somehow let users select different package versions. Normally, though, users don't actually want this -- when a new version is released, ordinarily all the old ones are obsolete. Another solution would be to have two repositories, one for stable packages and one for experimental. This wouldn't require any changes to package.el. Tom