On 30 April 2015 at 01:10, Xyne
On 2015-04-29 22:11 +0200 Magnus Therning wrote:
I've slowly been working away on some way to deal with the addition of x-revisions in Cabal files. My plan at the moment is to include it in the `pkgrel` in this way
haskell-zlib-0.5.4.2-76-x86_64.pkg.tar.xz
becomes
haskell-zlib-0.5.4.2-0.76-x86_64.pkg.tar.xz
given that the x-revision is 0.
This of course has the slight drawback that everyone will have to re-install all packages :(
I'd love to hear if anyone has a better suggestion, in particular if it means not having to re-install. (I think I've found a way that won't require a re-build.)
/M
The pkgrel should be an integer that is incremented by 1 with each release so it should not be included there. I don't know what x-revisions are but perhaps you can (ab)use the PKGBUILD "epoch" to managed them: https://wiki.archlinux.org/index.php/PKGBUILD#epoch
I know they are supposed to be integers, but it seems to work even if they are not :) Unfortunately epoch won't work :(
If not, can you explain what they are and how they are used?
An x-revision is a change made via Hackage. When a Haskell package is uploaded to Hackage it typically has no x-revision field (it's then treated as having x-revision 0). On each modification made via Hackage to the Cabal file in the index the x-revision is increased by 1 (allowed changes include, among a few other things, changing dependency ranges). This means that there effectively is a new version of the package, but the version number itself is untouched. So, instead of dealing with a pair of `(pgkver, pkgrel)` we now have a triple of `(pkgver,xrev,pkgrel)`. The issue then becomes how to convert this triple into a pair. In particular, how to do it so the version ordering rules that `pacman` uses results in the wanted behaviour. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus