RFQ: Proposal for new versioning of packages
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 -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay
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 If not, can you explain what they are and how they are used? Regards, Xyne
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
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.
The `pkgrel' must be an integer incremented by 1, but there are no defined format for `pkgver'. So why not using `pkgver_xrev-pkgrel' in which `pkgver_xrev' is the `pkgver' defined in the PKGBUILD? It is allowed to do so, will be strictly incrementing and respecting PKGBUILD rules. PS: underscores are allowed (https://wiki.archlinux.org/index.php/PKGBUILD#pkgver) ++ Fabien
On 30 April 2015 at 07:55, Fabien Dubosson
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.
The `pkgrel' must be an integer incremented by 1, but there are no defined format for `pkgver'. So why not using `pkgver_xrev-pkgrel' in which `pkgver_xrev' is the `pkgver' defined in the PKGBUILD? It is allowed to do so, will be strictly incrementing and respecting PKGBUILD rules.
PS: underscores are allowed (https://wiki.archlinux.org/index.php/PKGBUILD#pkgver)
The issue I'm worried about is that of trailing zeroes. Is 2.1_1 < 2.1.1_0? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
The issue I'm worried about is that of trailing zeroes. Is 2.1_1 < 2.1.1_0?
Seems so: =========================== $ mkdir TEMP; cd TEMP $ cat << EOL > PKGBUILD pkgname=dummy pkgver=2.1.1_0 pkgrel=1 pkgdesc="dummy package" arch=(any) url="http://" license=('GPL') source=() md5sums=() package() { msg "Dummy package" } EOL $ makepkg -fsic $ sed -i 's#2\.1\.1_0#2.1_1#' PKGBUILD $ makepkg -fsic =========================== pacman shows: warning: downgrading package dummy (2.1.1_0-1 => 2.1_1-1)
On 2015-04-30 08:25 +0200 Fabien Dubosson wrote:
The issue I'm worried about is that of trailing zeroes. Is 2.1_1 < 2.1.1_0?
warning: downgrading package dummy (2.1.1_0-1 => 2.1_1-1)
In case you were not aware of it, pacman provides an executable named "vercmp" to compare versions. It also provides a vercmp manpage to explain how ALPM's version comparison function works. $ vercmp 2.1_1 2.1.1_0 -1 The underscore system seems to work as expected. I was afraid that it would trigger alphanumeric comparisons (e.g. 2.3_0 > 2.24_0) but it does not: $ vercmp 2.r3_0 2.r24_0 -1 Regards, Xyne
In case you were not aware of it, pacman provides an executable named "vercmp" to compare versions. It also provides a vercmp manpage to explain how ALPM's version comparison function works.
$ vercmp 2.1_1 2.1.1_0 -1
I wasn't aware, thanks for the tip!
The underscore system seems to work as expected. I was afraid that it would trigger alphanumeric comparisons (e.g. 2.3_0 > 2.24_0) but it does not:
$ vercmp 2.r3_0 2.r24_0 -1
Good idea to think about and test this point. ++ Fab
On 30/04/15 06:55, Fabien Dubosson wrote:
The `pkgrel' must be an integer incremented by 1, but there are no defined format for `pkgver'. So why not using `pkgver_xrev-pkgrel' in which `pkgver_xrev' is the `pkgver' defined in the PKGBUILD? It is allowed to do so, will be strictly incrementing and respecting PKGBUILD rules.
PS: underscores are allowed (https://wiki.archlinux.org/index.php/PKGBUILD#pkgver)
I agree with Fabien's proposal, so long it won't cause issues with Pacman. Logically makes the most sense. The more to the left the closer to the upstream and feature-set. Combining xrev and pkgrel in a singe integer somehow is feasible but seems hack-ish and probably will need to get changed again in the future. -- SP
participants (4)
-
Fabien Dubosson -
Magnus Therning -
SP -
Xyne