The PVP ought to mention dependency bounds (Was: Growing Haskell Platform)
mail at joachim-breitner.de
Tue Dec 11 23:34:57 CET 2012
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
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-22.214.171.124 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.
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
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the Libraries