From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#19296: [PATCH] Package archives now have priorities. Date: Sun, 7 Dec 2014 07:55:20 -0800 (PST) Message-ID: References: <<20141207132244.A14A7200D1E@loki.jorgenschaefer.de> <20141207154316.1f2c5943@forcix> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1417967793 11753 80.91.229.3 (7 Dec 2014 15:56:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Dec 2014 15:56:33 +0000 (UTC) To: Jorgen Schaefer , 19296@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 07 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 1XxeC9-0006tM-4d for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Dec 2014 16:56:25 +0100 Original-Received: from localhost ([::1]:58303 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxeC5-0004LV-8O for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Dec 2014 10:56:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxeBu-0004LO-PL for bug-gnu-emacs@gnu.org; Sun, 07 Dec 2014 10:56:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxeBn-0003qz-5B for bug-gnu-emacs@gnu.org; Sun, 07 Dec 2014 10:56:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxeBn-0003qt-1O for bug-gnu-emacs@gnu.org; Sun, 07 Dec 2014 10:56:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XxeBm-000151-NH for bug-gnu-emacs@gnu.org; Sun, 07 Dec 2014 10:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Dec 2014 15:56: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.14179677294105 (code B ref 19296); Sun, 07 Dec 2014 15:56:02 +0000 Original-Received: (at 19296) by debbugs.gnu.org; 7 Dec 2014 15:55:29 +0000 Original-Received: from localhost ([127.0.0.1]:56397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XxeBE-000147-5k for submit@debbugs.gnu.org; Sun, 07 Dec 2014 10:55:29 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:47203) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XxeBA-00013w-Gi for 19296@debbugs.gnu.org; Sun, 07 Dec 2014 10:55:25 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id sB7FtL5M023400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 7 Dec 2014 15:55:22 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id sB7FtIt6009845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 7 Dec 2014 15:55:19 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id sB7FtIMw013545; Sun, 7 Dec 2014 15:55:18 GMT In-Reply-To: <20141207154316.1f2c5943@forcix> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:96938 Archived-At: > > Why is that good? Why should MELPA be given a lower priority? >=20 > MELPA provides unstable versions of packages. Baloney. Please stop pushing this myth. MELPA provides *packages*. Whether a package is "stable" or not, as far as one can tell from the outside, is only something (optionally) claimed by its developer. > To provide stable versions of packages, there is the "MELPA Stable" No. There is nothing more stable about the packages in "MELPA Stable" (according to the creator of MELPA and MELPA "Stable"). Again, this "stability" is merely a designation by the package maintainer, for *his* own convenience. If a package maintainer wants to distinguish two versions of a package, and call one of them "stable", s?he can choose to put the latter into "MELPA Stable". That's the stated purpose of "MELPA Stable". It was added because some package maintainers wanted two, distinguishable versions that users could choose from. That's all - the name means nothing more than that. It might well be that the version put into MELPA Stable is less stable than the one put into MELPA. > repository (among others, including GNU ELPA). As not all > packages in MELPA unstable There is no "MELPA unstable". That is a fiction. Even the creator of MELPA and "MELPA Stable" has said so, and that adding MELPA Stable was maybe not a great idea (my paraphrase). According to him, "MELPA Stable" is in maintenance mode. > are available in MELPA stable, users have to add both to their > archives list to get access to all packages. But due to the way > MELPA assigns version numbers, the unstable versions will always > override stable versions, even when both are available. Take it up with the MELPA maintainers if you have a complaint about the design of MELPA and its version numbers. Don't try to lock out MELPA for all Emacs users, just because you have a problem with MELPA. Don't make the many MELPA users jump through hoops to let package.el treat MELPA like any other repository. =20 > This patch will allow a setup that takes the newest version of a > package from GNU ELPA, MELPA stable or Marmalade, and only if ^^^^^^^ > there is no version available from any of these repositories, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > take the one available from MELPA unstable. IOW, you want to favor all other repositories over MELPA. That logic is flawed. This certainly should not be the hard-coded/default Emacs behavior. "Only if there is no version available from any of these repositories, take the one available from MELPA unstable." Sheesh. Why should MELPA (there is no "MELPA unstable") be usable ONLY if no version of the package is available from any other repositories? > No jumping through hoops required. It's a joke, right? You can get off the bus at your bus stop only if there are no other people on the bus. Prerequisite: get everyone else off the bus first. IOW, you are last. Oh - UNLESS you bring a note from your mother saying "Please allow my boy Jorgen to get off the bus without waiting until he is the only passenger left." > The current solution to this is to add all packages available > from non-MELPA unstable to `package-pinned-packages'. "Please allow my boy Jorgen..." Quite a "solution". Be fair. If you want to require notes from mothers, then do that for *every* package repository. Make it so that to get a package from *any* repository you need to pin the package to that repository. Then you will see what this amounts to. Then you will have something that is fair. And equally cumbersome for all. There is no reason to discriminate against MELPA, treating it differently. > The facility of priorities for repositories is widely available > in other package managers, e.g. in Debian's apt (see > apt_preferences(5)). I couldn't care less. Do they single out one repository like you have singled out MELPA, hard-coding things so that to use that repository a given package must *not be available anywhere else*? "only if there is no version available from any" other repository, "take the one available from" THE-BAD-BOY. Repository priorities can be expressed in a normal way, using a list or assigning priority values - with *no built-in prejudice* for or against any particular repository. There is no reason to blackball MELPA this way. Treat repositories the same a priori. Let only *users* prioritize them. > You can read more about the problems with MELPA's versioning system > here: http://blog.jorgenschaefer.de/2014/06/ > the-sorry-state-of-emacs-lisp-package.html You quote yourself... Wunderbar. You have a problem with MELPA. You should take up your problem with the MELPA designers & maintainers. Please do not impose this stuff on Emacs, trying to blackball MELPA. A sorry state, indeed. MELPA is the most widely used and the most useful repository we have, by far. If you don't want to use it then don't use it. Circulez ; il n'y a rien a voir.