GNU bug report logs - #19296
[PATCH] Package archives now have priorities.

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Jorgen Schaefer <forcer <at> forcix.cx>, 19296 <at> debbugs.gnu.org
Subject: bug#19296: [PATCH] Package archives now have priorities.
Date: Sun, 7 Dec 2014 07:55:20 -0800 (PST)

> > Why is that good?  Why should MELPA be given a lower priority?
> 
> 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.
 
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.