bug#19296: [PATCH] Package archives now have priorities.

[Stefan Monnier]

> What kind of behavior do we want, then? :-)

That's the first question, indeed.

> When I install a package by name using M-x package-install foo, I want
> to install the highest version of "foo" from any repository but MELPA
> if it is available, and if not, the highest version of "foo" from MELPA.

OK.

> When I installed a package from another repository than MELPA, and I
> ask package.el to upgrade all packages, I do not want to get an upgrade
> suggestion to MELPA.

OK.

> The problem you now mention is: What should happen if I installed a
> package from MELPA and it is now available from another repository?

Right.  Or, to more generally, as suggested by Achim:
- I've installed version V2 from repository R2
- there's a version V1 from repository R1
- V2 > V1
- yet V1 is more recent than V2 (because R1 and R2 use different
  versioning schemes).

> I don't think there is a good solution for that.

But that is the problem that causes most harm since people get stuck
with an old version.

> We could come up with an idea such as "if, at the time this repository
> was chosen, the package was not available from another repository, but
> now it is, it should ...", but that seems rather arcane and requires
> us to store a lot more information than we currently do.

Last time we discussed it, another suggestion was to supplement the
version info with a date info.  That doesn't in itself solve the
problem, but it does provide enough extra info that package.el could try
to be more clever.

BTW, there's yet another interesting situation to consider (which we've
had once in GNU ELPA for AucTeX):
- V2 is in R2, user installs it.
- Some problem is found in V2
- R2 reverts to V1
- User is never told that reverting to V1 is the recommended course of action

Now that I think about it, maybe a better solution (which will also
handle this last case) is to compare the old archive-contents for each
archive and use that diff as a basis to discover what is new (instead of
relying on version numbers).

This last approach suffers from the problem that this diff is naturally
transient, so we'd have to accumulate those diffs that can be relevant
to the user and stash them in some file until the user has properly been
told about it (and she should be allowed to do "sorry, can't deal with it
right now, please remind me later").


        Stefan