emacs-devel
[Top][All Lists]
Advanced

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

Re: MELPA version numbers


From: Sebastian Wiesner
Subject: Re: MELPA version numbers
Date: Fri, 2 Aug 2013 10:26:33 +0200

2013/8/1 Stefan Monnier <address@hidden>:
>> I think, ultimately this is not an MELPA problem, but a shortcoming of
>> package.el.  One of many others…
>
> Clearly, that's another way to look at it.  After all, package evolution
> is not always linear, so we may/will hit similar problems sooner or
> later, kind of like what happened back then with Ispell-4.
>
> But these non-linearities are exceptions, whereas the issue here is
> between different version numbers used for the very same
> linear evolution.
>
> A solution to both non-linearities cold be to add release-time as
> a package-property.  So package.el could then warn the user "there's
> a newer package with an older version number, you might want to look at
> it".

That's not what I meant.  I don't think that the problem is in
versioning at all.  Rather the problem is the insufficient tracking of
multiple archives in package.el.

It doesn't track archives independently, and though it actually stores
the origin of a package, it doesn't make any use of this information
at all. These limitations sort of defeat the purpose of having
multiple archives imho.

Ideally, package.el would track *all* packages of *all* repositories
in "package-archive-contents" (not just the latest out of all
repositories), so that packages, which are contained in multiple
archives, also appear multiple times in M-x list-packages, once for
each archive.

The user could then choose from which archive a package should be
installed.  And package.el would remember this choice, and look for
updates only in the archive the package was installed from.  If this
archive is no longer contained in "package-archive-contents",
package.el would warn the user, and offer to look for the package in
other archives.

To explicitly “switch” archives for a single package, the user would
just explicitly install the package from another archive, implicitly
telling packages to “pin” this package to the new archive from now on.

This more sophisticated way of tracking archives would not only neatly
solve the problem of MELPA version numbers (without even touching
them), but also a number of other issues with package.el, such as the
popular demand to be able to explicitly choose for each package
whether to use a stable release from GNU ELPA or Marmalade, or a VCS
snapshot from MELPA.

And it'd give *users* control about archives and the ability to choose.



reply via email to

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