From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jorgen Schaefer Newsgroups: gmane.emacs.bugs Subject: bug#19296: [PATCH] Package archives now have priorities. Date: Sun, 7 Dec 2014 19:21:05 +0100 Message-ID: <20141207192105.48c4c41b@forcix> References: <20141207132244.A14A7200D1E@loki.jorgenschaefer.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1417976544 11522 80.91.229.3 (7 Dec 2014 18:22:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Dec 2014 18:22:24 +0000 (UTC) Cc: 19296@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 07 19:22:18 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 1XxgTI-0001JY-EB for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Dec 2014 19:22:16 +0100 Original-Received: from localhost ([::1]:58822 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxgTI-00021g-0b for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Dec 2014 13:22:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxgT9-000216-SL for bug-gnu-emacs@gnu.org; Sun, 07 Dec 2014 13:22:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxgT4-0006x3-II for bug-gnu-emacs@gnu.org; Sun, 07 Dec 2014 13:22:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59277) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxgT4-0006wv-EU for bug-gnu-emacs@gnu.org; Sun, 07 Dec 2014 13:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XxgT3-00065B-W6 for bug-gnu-emacs@gnu.org; Sun, 07 Dec 2014 13:22:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jorgen Schaefer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Dec 2014 18:22:01 +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.141797647023312 (code B ref 19296); Sun, 07 Dec 2014 18:22:01 +0000 Original-Received: (at 19296) by debbugs.gnu.org; 7 Dec 2014 18:21:10 +0000 Original-Received: from localhost ([127.0.0.1]:56489 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XxgSE-00063w-7e for submit@debbugs.gnu.org; Sun, 07 Dec 2014 13:21:10 -0500 Original-Received: from loki.jorgenschaefer.de ([87.230.15.51]:38274) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XxgSC-00063n-02 for 19296@debbugs.gnu.org; Sun, 07 Dec 2014 13:21:09 -0500 Original-Received: by loki.jorgenschaefer.de (Postfix, from userid 998) id D3A23200D20; Sun, 7 Dec 2014 19:21:06 +0100 (CET) Original-Received: from forcix (port-21631.pppoe.wtnet.de [46.59.146.42]) by loki.jorgenschaefer.de (Postfix) with ESMTPSA id 38BAB200D1D; Sun, 7 Dec 2014 19:21:06 +0100 (CET) In-Reply-To: X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; i586-pc-linux-gnu) 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:96953 Archived-At: On Sun, 07 Dec 2014 12:56:53 -0500 Stefan Monnier wrote: > > When installing packages by name, only packages from archives with > > the highest priority are considered, before versions are compared. > > What can this be used for (other than the MELPA case, obviously)? Local/site-wide package archives that provide specific versions for packages that are required by the site that should not be overridden by external sources. (Can be emulated by pinning them.) Adding archives that provide testing or debugging packages which should not be installed by default, but can be installed by the user if they want to. (Can be emulated by adding the archive only for the duration of installing those packages.) More generally, the use cases are either very similar to the existing "pinning" functionality, or to adding archives only temporarily, except the interface is easier to the user and does not require constant manual work. > > This solves the "MELPA problem", where MELPA assigns date-based > > version numbers to packages which override all other archives. > > Giving MELPA a lower priority means packages are installed from > > MELPA only when the package is not available from other archives. > > I think the better way to solve the problem of versioning the > "bleeding edge package" would be to take the base version and tuck > the date to it (instead of only using the date). > I.e. file names like foo-mode-1.3.0.20141023.tar.gz where "1.3" is the > version of the last release. > > Of course that requires a change on MELPA side and I have no idea how > easy/feasible that would be. And I'm not completely sure it would > really be the best option either. This is not easy for the general MELPA, as not all packages have version numbers at all, but certainly feasible for MELPA stable. My patch that would have added this was rejected: https://github.com/milkypostman/melpa/pull/1771 The version number issues has been raised a few times, and it does not seem likely to get fixed any time soon. > > This can be overridden manually by the user. > > An important issue is what happens after the user did such an > override. In my above suggestion, the behavior would kind of suck > since package-list would then constantly recommend "upgrading" to the > official release (since 1.3 is "more uptodate" than "0.0.YYYYMMDD"). Good point. The correct implementation here would likely move the sorting by version number out of the `package--add-to-archive-contents' function and into the various users of `package-archive-contents', which should sort the list depending on their use case. This is a breaking API change and likely a good deal more work. Would a patch that does that be more acceptable? Regards, Jorgen