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

Hi, Am Dienstag, den 11.12.2012, 08:14 -0800 schrieb Johan Tibell:

On Tue, Dec 11, 2012 at 1:45 AM, Simon Marlow 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@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/