From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#19296: [PATCH] Package archives now have priorities. Date: Mon, 08 Dec 2014 10:42:49 -0500 Message-ID: References: <20141207132244.A14A7200D1E@loki.jorgenschaefer.de> <20141207192105.48c4c41b@forcix> <20141207210038.384c7e84@forcix> <20141208115845.1adaa261@forcix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1418054192 12993 80.91.229.3 (8 Dec 2014 15:56:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Dec 2014 15:56:32 +0000 (UTC) Cc: 19296@debbugs.gnu.org To: Jorgen Schaefer Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 08 16:56:26 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xy0fg-0002pn-1B for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Dec 2014 16:56:24 +0100 Original-Received: from localhost ([::1]:34660 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xy0ff-0004kQ-Lh for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Dec 2014 10:56:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xy0fS-0004Ye-WA for bug-gnu-emacs@gnu.org; Mon, 08 Dec 2014 10:56:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xy0fL-00068K-Ez for bug-gnu-emacs@gnu.org; Mon, 08 Dec 2014 10:56:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:60598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xy0fL-000687-CV for bug-gnu-emacs@gnu.org; Mon, 08 Dec 2014 10:56:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Xy0Sk-0000T0-CK for bug-gnu-emacs@gnu.org; Mon, 08 Dec 2014 10:43:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Dec 2014 15:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19296 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 19296-submit@debbugs.gnu.org id=B19296.14180533751769 (code B ref 19296); Mon, 08 Dec 2014 15:43:02 +0000 Original-Received: (at 19296) by debbugs.gnu.org; 8 Dec 2014 15:42:55 +0000 Original-Received: from localhost ([127.0.0.1]:57802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xy0Sc-0000ST-8F for submit@debbugs.gnu.org; Mon, 08 Dec 2014 10:42:54 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:56177) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xy0SY-0000SF-2W for 19296@debbugs.gnu.org; Mon, 08 Dec 2014 10:42:51 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwPAOwQflRFxLi7/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQMBViMFCwsOJhIUGA0kLogcCdZZAQEBAQYBAQEBHpBvB4RIBYsBjFUFhVeDOI5FgXiEGSGCdwEBAQ X-IPAS-Result: AjwPAOwQflRFxLi7/2dsb2JhbABbgweDYIVaxR0EAgKBJBcBAQEBAQF8hAMBAQMBViMFCwsOJhIUGA0kLogcCdZZAQEBAQYBAQEBHpBvB4RIBYsBjFUFhVeDOI5FgXiEGSGCdwEBAQ X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="99869624" Original-Received: from 69-196-184-187.dsl.teksavvy.com (HELO ceviche.home) ([69.196.184.187]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2014 10:42:49 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 0E7CE66162; Mon, 8 Dec 2014 10:42:49 -0500 (EST) In-Reply-To: <20141208115845.1adaa261@forcix> (Jorgen Schaefer's message of "Mon, 8 Dec 2014 11:58:45 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:96996 Archived-At: > 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