Sifflet dependencies
$ cabal update Downloading the latest package list from hackage.haskell.org $ cabal install sifflet Resolving dependencies... cabal: cannot configure pango-0.11.1. It requires cairo >=0.11.1 && <0.12 and glib >=0.11.1 && <0.12 For the dependency on cairo >=0.11.1 && <0.12 there are these packages: cairo-0.11.1. However none of them are available. cairo-0.11.1 was excluded because sifflet-lib-1.0 requires cairo ==0.11.0 cairo-0.11.1 was excluded because cairo-0.11.0 was selected instead cairo-0.11.1 was excluded because sifflet-1.0 requires cairo ==0.11.0 For the dependency on glib >=0.11.1 && <0.12 there are these packages: glib-0.11.1. However none of them are available. glib-0.11.1 was excluded because sifflet-lib-1.0 requires glib ==0.11.0 glib-0.11.1 was excluded because glib-0.11.0 was selected instead glib-0.11.1 was excluded because sifflet-1.0 requires glib ==0.11.0 So that's pretty simple. 'sifflet' requires cairo ==0.11.0 and pango. But since pango doesn't work with cairo 0.11.0, the package can't be built. The solution is to ask the sifflet author to adjust the dependencies to be more flexible. http://hackage.haskell.org/package/sifflet Those specific versions of packages are overly constrained. They should follow the PVP, and be thus, 0.11.* -- Don
Hi, according to this page: http://hackage.haskell.org/package/pango-0.11.0 pango should work with cairo 0.11.0 (or any other 0.11.* version) So it seems that the problem is that cabal tried to use pango-0.11.1, and I am guessing that it does not backtrack and try an older version if a build fails (which is reasonable). So why did Cabal choose pango-0.11.1? Because gtk-0.11.0 claims to work with _any_ 0.11.* version of pango and cairo, so Cabal just picked the latest one. Therefore, the problem seems to be with the dependencies of gtk-0.11.0 and pango-0.11.0 (indeed, later versions of gtk have more precise dependencies). Unfortunately, we have no way of improving the dependencies of a package without changing its version, which suggests that it is never safe to depend on gtk-0.11.0. This might be something that we should look into, but in the meantime, it may be better to make sifflet depend on a later specific version of "gtk" (e.g., 0.11.2) rather then claiming that works with any 0.11.* version. By the way, it is unfortunate that packages which only differ in their third version field (e.g., 0.11.0 vs 0.11.1) are incompatible with each other, I thought that the recommendation was to increase the second version field to avoid that. -Iavor On Mon, Aug 16, 2010 at 12:56 PM, Don Stewart <dons@galois.com> wrote:
$ cabal update Downloading the latest package list from hackage.haskell.org
$ cabal install sifflet Resolving dependencies... cabal: cannot configure pango-0.11.1. It requires cairo >=0.11.1 && <0.12 and glib >=0.11.1 && <0.12 For the dependency on cairo >=0.11.1 && <0.12 there are these packages:
cairo-0.11.1. However none of them are available. cairo-0.11.1 was excluded because sifflet-lib-1.0 requires cairo ==0.11.0 cairo-0.11.1 was excluded because cairo-0.11.0 was selected instead cairo-0.11.1 was excluded because sifflet-1.0 requires cairo ==0.11.0
For the dependency on glib >=0.11.1 && <0.12 there are these packages: glib-0.11.1. However none of them are available. glib-0.11.1 was excluded because sifflet-lib-1.0 requires glib ==0.11.0 glib-0.11.1 was excluded because glib-0.11.0 was selected instead glib-0.11.1 was excluded because sifflet-1.0 requires glib ==0.11.0
So that's pretty simple. 'sifflet' requires cairo ==0.11.0 and pango. But since pango doesn't work with cairo 0.11.0, the package can't be built. The solution is to ask the sifflet author to adjust the dependencies to be more flexible.
http://hackage.haskell.org/package/sifflet
Those specific versions of packages are overly constrained. They should follow the PVP, and be thus,
0.11.*
-- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Don Stewart wrote:
So that's pretty simple.
This is one of those "2 > 3 for sufficiently large 2" things, eh? ;-)
'sifflet' requires cairo ==0.11.0 and pango.
Indeed.
But since pango doesn't work with cairo 0.11.0, the package can't be built.
Uh... it seemed to build just fine for me (when I did it all manually). I'm not sure I see what the problem is here. I made Cabal install 0.11.0 of each package, by hand, one at a time, and it never complained of any unfulfilled dependencies, and the end result was a runnable program. So I'm just puzzled why it couldn't figure out that you can do that by itself.
Those specific versions of packages are overly constrained. They should follow the PVP, and be thus,
0.11.*
Yeah, that seems to be the root of the problem.
Short answer: I had reasons for constraining gtk, etc., to be == 0.11.0. I will check whether the suggested changes work, and if they do, include them in the next release of sifflet and sifflet-lib. Longer answer (quoting parts of 3 different messages): From: Don Stewart <dons@galois.com>
So that's pretty simple. 'sifflet' requires cairo ==0.11.0 and pango. But since pango doesn't work with cairo 0.11.0, the package can't be built. The solution is to ask the sifflet author to adjust the dependencies to be more flexible.
Those specific versions of packages are overly constrained. They should follow the PVP, and be thus,
0.11.*
"'sifflet' requires ... pango" confused me at first. Neither sifflet nor sifflet-lib 1.0 requires pango explicitly. However, they both require gtk == 0.11.0, and gtk 0.11.0 requires pango 0.11.*. Okay, so that must be how pango got involved in this. Your suggestion, then, is for me ("the sifflet author") to change {sifflet,sifflet-lib}.cabal files to read in part: build-depends: ... cairo == 0.11.*, glib == 0.11.*, gtk == 0.11.*, In the past, I've gotten into trouble with looser version constraints on the gtk2hs package(s), that is, gtk, cairo, glib, and associates. I had written a function for changing the cursor (the image that shows where the mouse is pointing), because this function was not present in the then current version of gtk2hs. Then I got a new version of gtk2hs which added the missing function, and so broke my code because we now had multiple definitions of the same-named functions. However, this new version of gtk2hs did *not* have a significantly different version number from the old. So I became very cautious about the upper bounds for the version numbers of the gtk2hs package(s). (In fact, the situation was even a little crazier! This happened when I switched from Fedora to Arch Linux, and the Arch Linux package I believe was pulling the code from a darcs or subversion repository that was "in advance" of the latest "released" package. In effect, the *version* had changed, but the version *number* had not changed!) From: Andrew Coppin <andrewcoppin@btinternet.com> ...
Uh... it seemed to build just fine for me (when I did it all manually). I'm not sure I see what the problem is here. I made Cabal install 0.11.0 of each package, by hand, one at a time, and it never complained of any unfulfilled dependencies, and the end result was a runnable program. So I'm just puzzled why it couldn't figure out that you can do that by itself.
Glad that it worked that way, at least, but sorry you had to go to such trouble. I was about to ask you to tinker with the cabal files for me and see if 0.11.* or 0.11.2 also work, but since the Arch Linux User Repository now has these versions available for me, I will do the tinkering myself. From: Iavor Diatchki <iavor.diatchki@gmail.com> ...
but in the meantime, it may be better to make sifflet depend on a later specific version of "gtk" (e.g., 0.11.2) rather then claiming that works with any 0.11.* version.
I believe you are suggesting something like gtk >= 0.11.0 && < 0.11.3 ?? Greg
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- ___ ___ __ _ / _ \ / _ \| | | | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \____/\_____/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550
Don Stewart wrote:
Those specific versions of packages are overly constrained. They should follow the PVP.
While we're on the subject... Suppose I have a package, which I know works with foo-8.7.2. What should the Cabal dependents field say? We have a choice of foo == 8.7.2 foo >= 8.7.2 foo >= 8.7 foo >= 8.7 && < 8.8 foo == 8.7.* So which one is the "correct" one? Based on your responses, I'm guessing it's supposed to be the last one...
On Tue, Aug 17, 2010 at 2:54 PM, Andrew Coppin <andrewcoppin@btinternet.com> wrote:
While we're on the subject... Suppose I have a package, which I know works with foo-8.7.2. What should the Cabal dependents field say? We have a choice of
foo == 8.7.2 foo >= 8.7.2 foo >= 8.7 foo >= 8.7 && < 8.8 foo == 8.7.*
I'd like to add another option since it's the one I use, foo >= 8.7.2 && < 8.8 Anthony
On 18 August 2010 05:04, Anthony Cowley <acowley@seas.upenn.edu> wrote:
On Tue, Aug 17, 2010 at 2:54 PM, Andrew Coppin <andrewcoppin@btinternet.com> wrote:
While we're on the subject... Suppose I have a package, which I know works with foo-8.7.2. What should the Cabal dependents field say? We have a choice of
foo == 8.7.2 foo >= 8.7.2 foo >= 8.7 foo >= 8.7 && < 8.8 foo == 8.7.*
I'd like to add another option since it's the one I use,
foo >= 8.7.2 && < 8.8
If the package in question uses features added in version 8.7.2 of foo (and foo follows the PVP), then this is the correct syntax to use. If, however, it will also build with 8.7, then ">= 8.7 && < 8.8" (or just "== 8.7.*") should be used. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
participants (6)
-
Andrew Coppin -
Anthony Cowley -
Don Stewart -
gdweber＠iue.edu -
Iavor Diatchki -
Ivan Lazar Miljenovic