Hi Magnus,
Now you make me think that I might have missed something, but surely parsec version 2.2 wouldn't satisfy the former, but would satisfy the latter.
yes, this is true, of course. It is impossible to map that Cabal expression to Pacman without losing some information. In this particular case, that restriction is lost. If a version 2.2 of parsec were to come out, and if we were to decide to ship that version, then we'd have to update the email-validate PKGBUILD in order to fix the build. Now, the alternative is to encode the Cabal expression in question as ('parsec>=2.1.0' 'parsec<2.2'). That choice means that email-validate won't build anymore if we decide to upgrade to parsec 3. In a way, both solutions are equally inaccurate, so we can choose either one. I just happen to prefer the first solution because I feel that an upgrade to parsec 3 is far more likely to occur than an upgrade to 2.2, simply because parsec 3 exists, but parsec 2.2 does not. Does that make sense? Take care, Peter