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

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.*

"'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 ...

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 ...

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

On Tue, Aug 17, 2010 at 2:54 PM, Andrew Coppin 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