From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Eric M. Ludlam" Newsgroups: gmane.emacs.devel Subject: Re: Emacs Package Management Date: Thu, 17 Sep 2009 11:04:54 -0400 Message-ID: <1253199894.4770.1096.camel@projectile.siege-engine.com> References: <485b0c380808011427n4d3144eey3f8daf3abac83bf4@mail.gmail.com> <87d45vzt4j.fsf@hagelb.org> <87hbv20ybw.fsf@thinkpad.tsdh.de> <87d45p29zr.fsf@thinkpad.tsdh.de> Reply-To: eric@siege-engine.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1253199836 10029 80.91.229.12 (17 Sep 2009 15:03:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Sep 2009 15:03:56 +0000 (UTC) Cc: Tom Tromey , phil@hagelb.org, rms@gnu.org, joakim@verona.se, emacs-devel@gnu.org To: Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 17 17:03:46 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 1MoIWF-0001Pa-Tf for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2009 17:03:36 +0200 Original-Received: from localhost ([127.0.0.1]:41369 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MoIWF-0005NM-39 for ged-emacs-devel@m.gmane.org; Thu, 17 Sep 2009 11:03:35 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MoIW4-0005LG-PM for emacs-devel@gnu.org; Thu, 17 Sep 2009 11:03:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MoIW4-0005Kq-2k for emacs-devel@gnu.org; Thu, 17 Sep 2009 11:03:24 -0400 Original-Received: from [199.232.76.173] (port=48960 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MoIW3-0005Kn-ER for emacs-devel@gnu.org; Thu, 17 Sep 2009 11:03:23 -0400 Original-Received: from static-71-184-83-10.bstnma.fios.verizon.net ([71.184.83.10]:38226 helo=projectile.siege-engine.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MoIVz-0001yZ-Sf; Thu, 17 Sep 2009 11:03:20 -0400 Original-Received: from projectile.siege-engine.com (localhost [127.0.0.1]) by projectile.siege-engine.com (8.14.3/8.14.3/Debian-6) with ESMTP id n8HF4tEi027506; Thu, 17 Sep 2009 11:04:55 -0400 Original-Received: (from zappo@localhost) by projectile.siege-engine.com (8.14.3/8.14.3/Submit) id n8HF4sGv027505; Thu, 17 Sep 2009 11:04:54 -0400 X-Authentication-Warning: projectile.siege-engine.com: zappo set sender to eric@siege-engine.com using -f In-Reply-To: <87d45p29zr.fsf@thinkpad.tsdh.de> X-Mailer: Evolution 2.26.1 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:115418 Archived-At: Hi, The inversion tool I wrote a while back: http://www.emacswiki.org/emacs/InVersion is part of CEDET which will eventually be part of Emacs. I wrote it due to the many version dependencies my users were dealing with. It supports the basic concepts displayed below. It is used to validate versions of save files, and versions of packages required by other packages. It does so based on a version stored in some Lisp file as a defvar instead of some new declaration because that was something that was prevalent in miscellaneous other sources I didn't write. Perhaps it would prove useful here too. Eric On Thu, 2009-09-17 at 11:31 +0200, Tassilo Horn wrote: > joakim@verona.se writes: > > >> But the newest package might not run on an older emacs version. So > >> it would be good if package.el would show the latest version of a > >> package that is supposed to work with my emacs version, and if it > >> requires other packages, then their versions have to be taken into > >> account, too. Does it do something like that? > > > > The way most distros seems to solve this is to simply have different > > repos for different distro versions. That should work for package.el > > also. We could even adopt the stable/testing/bleeding scheme, so 3 > > repos for every supported major emacs version. > > I don't think that's a good approach, because it requires a lot of > maintenance and testing on the package repository side. It would be > better if a package could specify something like > > (package "my-package" > (version "1.0") > (need ">=emacs-23")) > > (package "my-package" > (version "0.8") > (need ">=emacs-22.1" " > and package.el does the resolving. So when I run emacs 22, package.el > would show version 0.8 of my-package, with emacs 23 it would show > version 1.0, and with emacs 21 it wouldn't be shown as not installable. > > In the latter case, it would be good if a user could figure out why it's > not installable. > > Of course, in the `need' dependency list, there could also be other > external packages. For example, there could be > > (package "my-package" > (version "1.0") > (need ">=emacs-23" ">=foo-mode-0.7")) > > so package.el on emacs 23 should show my-package 1.0 to be installable > only if some version >= 0.7 of foo-mode is installable, too. When I > select it to be installed, then the newest foo-mode should be installed, > too. > > So basically for each package version starting with the newest, the > packages in `need' have to be checked for availability/installability > recursively. The first version where all needs can be satisfied, is the > one displayed. > > Another issue is updating. There the question is: Can I update package > A without breaking any other package that needs it? > > Bye, > Tassilo > >