emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Package Management


From: Tassilo Horn
Subject: Re: Emacs Package Management
Date: Thu, 17 Sep 2009 11:31:20 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

address@hidden 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]