The PVP ought to mention dependency bounds (Was: Growing Haskell Platform)

[Joachim Breitner]

Hi,

Am Dienstag, den 11.12.2012, 08:14 -0800 schrieb Johan Tibell:
> On Tue, Dec 11, 2012 at 1:45 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> > I'm a bit lost.  The example from your mail that started this thread *does*
> > compile, because Cabal finds a valid install plan by avoiding the new
> > version of B. It's working exactly as intended, isn't it?  Then you said
> > that the user might get confused about why the new B wasn't being used, to
> > which the response is that we need better diagnostics.
> >
> > What's the problem you're getting at above?
> 
> The problem is one of two things, depending on how you look at it. On
> the one hand, if we take "C-1.0 depends on A-1.0.0.*" to mean that C
> states that it can work with any version of A-1.0.0, that is a lie (as
> per the scenario in my original email) and the PVP needs to be
> adjusted.

I don’t think this is a good semantics for the dependency. I always
understand package dependencies as: If you find a set of packaging such
that all constraints are fulfilled, then things will build correctly.

What if A-1.0.0.1 would fail for other reasons, besides a bumped
dependency? E.g. A decides to implement an internal parser with happy,
and adds that to the list of tools required. Now people who could build
C before, but don’t have happy installed, cannot build C. But should
that really require A to bump a major version?

> On the other hand, if you take "C-1.0 depends on A-1.0.0.*" to mean
> that C states that it can work with the A-1.0.0 API then users and
> developers might get confused when newer releases of libraries don't
> get picked up even though the version bounds suggests that they would.

A user should not worry about that. What he expects is to do cabal
install and get some working installation. Or better, a User would use
stackage or a distribution, where such issues are taken care of.

A developer can be expected to know about these issue and be able to
cope with it. And for her

> We could try to solve this by cabal telling the user about when this
> situation appears, but understanding why package version conflicts
> appear is already hard to understand for users.

would indeed be useful.


And, as always, with my Debian maintainer hat on: I’d prefer not to see
unnecessary meta data changes (as long as the promise above is
preserved), as they cause work for us.

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
  mail at joachim-breitner.de  |  nomeata at debian.org  |  GPG: 0x4743206C
  xmpp: nomeata at joachim-breitner.de | http://www.joachim-breitner.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121211/539e7de0/attachment.pgp>