On 03/01/11 19:49, Peter Simons wrote:
> 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?In this particular example I have a feeling that it's parsec that is the problem ;-) Staying with parsec though, would it make sense to take HP in consideration when converting the dependencies? I.e, when the CABAL dependency says "parsec >= 3.0 || == 2.1.*" then we choose "parsec>=2.1.0, parsec<2.2.0" simply because that's the version in HP. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: [email protected] jabber: [email protected] twitter: magthe http://therning.org/magnus
signature.asc
Description: OpenPGP digital signature
_______________________________________________ arch-haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/arch-haskell
