From: "Eric M. Ludlam" <eric@siege-engine.com>
To: Tassilo Horn <tassilo@member.fsf.org>
Cc: Tom Tromey <tromey@redhat.com>,
phil@hagelb.org, rms@gnu.org, joakim@verona.se,
emacs-devel@gnu.org
Subject: Re: Emacs Package Management
Date: Thu, 17 Sep 2009 11:04:54 -0400 [thread overview]
Message-ID: <1253199894.4770.1096.camel@projectile.siege-engine.com> (raw)
In-Reply-To: <87d45p29zr.fsf@thinkpad.tsdh.de>
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" "<emacs-23"))
>
> 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
>
>
next prev parent reply other threads:[~2009-09-17 15:04 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-01 21:27 Emacs Package Management Stephen Eilert
2008-08-01 22:58 ` Tom Tromey
2008-08-01 23:14 ` Phil Hagelberg
2008-08-01 23:25 ` Lennart Borgman (gmail)
2008-08-02 0:13 ` Tom Tromey
2008-08-03 1:33 ` Richard M. Stallman
2008-08-03 18:03 ` Stefan Monnier
2008-08-04 15:33 ` Richard M. Stallman
2008-08-04 19:07 ` Stefan Monnier
2008-08-05 8:04 ` Richard M. Stallman
2008-08-05 13:09 ` Stephen Eilert
2008-08-05 14:39 ` Paul R
2008-08-06 3:35 ` Richard M. Stallman
2009-09-16 22:36 ` Stephen Eilert
2009-09-17 1:44 ` Tom Tromey
2009-09-17 13:43 ` Stefan Monnier
2009-09-17 14:26 ` Tom Tromey
2009-09-17 14:58 ` Eric M. Ludlam
2009-09-28 21:13 ` Phil Hagelberg
2009-09-28 21:48 ` Lennart Borgman
2009-09-28 21:54 ` Chong Yidong
2009-09-28 22:30 ` Phil Hagelberg
2009-09-29 11:31 ` Richard Stallman
2009-09-29 19:18 ` Stefan Monnier
2009-09-29 19:41 ` Tom Tromey
2009-09-30 1:20 ` Stefan Monnier
2009-09-30 2:07 ` Tom Tromey
2009-09-30 4:39 ` Stefan Monnier
2009-09-30 20:18 ` Tom Tromey
2009-10-01 5:01 ` Stefan Monnier
2008-08-02 1:58 ` Stephen Eilert
2008-08-02 3:36 ` Tom Tromey
2008-08-02 17:30 ` Richard M Stallman
2008-08-12 4:10 ` Thomas Lord
2009-09-12 22:38 ` Phil Hagelberg
2009-09-12 23:30 ` Eric M. Ludlam
2009-09-13 16:40 ` Richard Stallman
2009-09-14 9:07 ` joakim
2009-09-14 9:26 ` David Kastrup
2009-09-15 7:16 ` Richard Stallman
2009-09-15 8:30 ` Miles Bader
2009-09-15 18:15 ` Richard Stallman
2009-09-15 18:58 ` Tom Tromey
2009-09-15 22:08 ` Miles Bader
2009-09-16 15:16 ` Richard Stallman
2009-09-16 18:41 ` Stefan Monnier
2009-09-17 1:05 ` Geoff Gole
2009-09-17 19:50 ` Richard Stallman
2009-09-15 18:55 ` Tom Tromey
2009-09-17 6:37 ` Richard Stallman
2009-09-17 8:28 ` Tassilo Horn
2009-09-17 8:37 ` joakim
2009-09-17 8:48 ` Lennart Borgman
2009-09-17 9:31 ` Tassilo Horn
2009-09-17 10:43 ` Lennart Borgman
2009-09-17 11:50 ` Rupert Swarbrick
2009-09-19 2:40 ` Bob Rogers
2009-09-19 12:10 ` Rupert Swarbrick
2009-09-17 14:24 ` Tom Tromey
2009-09-17 19:22 ` Tassilo Horn
2009-09-17 15:04 ` Eric M. Ludlam [this message]
2009-09-17 13:46 ` Stefan Monnier
2009-09-17 14:21 ` Tom Tromey
2009-09-13 17:00 ` Eric Schulte
2008-08-02 14:46 ` Paul R
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1253199894.4770.1096.camel@projectile.siege-engine.com \
--to=eric@siege-engine.com \
--cc=emacs-devel@gnu.org \
--cc=joakim@verona.se \
--cc=phil@hagelb.org \
--cc=rms@gnu.org \
--cc=tassilo@member.fsf.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.