From: Tassilo Horn <tassilo@member.fsf.org>
To: joakim@verona.se
Cc: Tom Tromey <tromey@redhat.com>,
emacs-devel@gnu.org, rms@gnu.org, phil@hagelb.org
Subject: Re: Emacs Package Management
Date: Thu, 17 Sep 2009 11:31:20 +0200 [thread overview]
Message-ID: <87d45p29zr.fsf@thinkpad.tsdh.de> (raw)
In-Reply-To: <m3ljkec6gj.fsf@verona.se> (joakim@verona.se's message of "Thu, 17 Sep 2009 10:37:32 +0200")
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 9:31 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 [this message]
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
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=87d45p29zr.fsf@thinkpad.tsdh.de \
--to=tassilo@member.fsf.org \
--cc=emacs-devel@gnu.org \
--cc=joakim@verona.se \
--cc=phil@hagelb.org \
--cc=rms@gnu.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.