Fwd: RFQ: Proposal for new versioning of packages

Nicola Squartini

30 Apr 2015 30 Apr '15

4:21 a.m.

Sorry, keep replying to one person only instead of the mailing list. How about the other way around: if xrev == 0 --> haskell-zlib-0.5.4.2-76-x86_64.pkg.tar.xz if xrev == n && n > 0 --> haskell-zlib-0.5.4.2-76.n-x86_64.pkg.tar.xz Nicola On Thu, Apr 30, 2015 at 8:10 AM, Xyne wrote:

...

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 _______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/arch-haskell

Attachments:

attachment.html (text/html — 2.4 KB)

Show replies by date

Magnus Therning

30 Apr 30 Apr

4:59 a.m.

New subject: Fwd: RFQ: Proposal for new versioning of packages

On 30 April 2015 at 10:21, Nicola Squartini wrote:

...

Sorry, keep replying to one person only instead of the mailing list.

How about the other way around:

if xrev == 0 --> haskell-zlib-0.5.4.2-76-x86_64.pkg.tar.xz if xrev == n && n > 0 --> haskell-zlib-0.5.4.2-76.n-x86_64.pkg.tar.xz

There are implementation details in `cblrepo` that make things a lot easier if the release number is reset when a package is added (an update is treated as an addition of an already existing package). As it is now the algorithm doesn't keep track of packages that are updated, but with your scheme it would have to (the release number must be carried over). Furthermore, if the algorithm is modified in that way there is no need to even include the x-revision at all, it can all be "hidden" in a bump of the release number. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

Nicola Squartini

6:07 a.m.

New subject: Fwd: RFQ: Proposal for new versioning of packages

Release numbers would still be reset on adding: xrev == 0 --> haskell-zlib-0.5.4.2-76-x86_64.pkg.tar.xz add xrev == n && n > 0 --> haskell-zlib-0.5.4.2-1.n-x86_64.pkg.tar.xz add <next ver>, xrev == 0 -->haskell-zlib-<next ver>-1-x86_64.pkg.tar.xz The only concern that I have with your versioning is that having 0.x in the release number might suggest that the package is still in a testing stage. And I make xrev == 0 first class (not adding the ".n") because I believe Hackage revisions are ugly and should not exist. Anyway, whatever scheme you choose it's good for me :) On Thu, Apr 30, 2015 at 5:59 PM, Magnus Therning wrote:

...

On 30 April 2015 at 10:21, Nicola Squartini wrote:

...
Sorry, keep replying to one person only instead of the mailing list.

How about the other way around:

if xrev == 0 --> haskell-zlib-0.5.4.2-76-x86_64.pkg.tar.xz if xrev == n && n > 0 --> haskell-zlib-0.5.4.2-76.n-x86_64.pkg.tar.xz

There are implementation details in `cblrepo` that make things a lot easier if the release number is reset when a package is added (an update is treated as an addition of an already existing package). As it is now the algorithm doesn't keep track of packages that are updated, but with your scheme it would have to (the release number must be carried over). Furthermore, if the algorithm is modified in that way there is no need to even include the x-revision at all, it can all be "hidden" in a bump of the release number.

/M

-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

Magnus Therning

1 May 1 May

2:42 a.m.

New subject: Fwd: RFQ: Proposal for new versioning of packages

On Thu, Apr 30, 2015 at 07:07:48PM +0900, Nicola Squartini wrote:

...

Release numbers would still be reset on adding:

xrev == 0 --> haskell-zlib-0.5.4.2-76-x86_64.pkg.tar.xz add xrev == n && n > 0 --> haskell-zlib-0.5.4.2-1.n-x86_64.pkg.tar.xz add <next ver>, xrev == 0 -->haskell-zlib-<next ver>-1-x86_64.pkg.tar.xz

The only concern that I have with your versioning is that having 0.x in the release number might suggest that the package is still in a testing stage. And I make xrev == 0 first class (not adding the ".n") because I believe Hackage revisions are ugly and should not exist. Anyway, whatever scheme you choose it's good for me :)

It's addition after bump of x-revision that I worry about: xrev == 0 --> haskell-zlib-0.5.4.2-76-x86_64.pkg.tar.xz add xrev == n && n > 0 --> haskell-zlib-0.5.4.2-1.n-x86_64.pkg.tar.xz rebuild --> haskell-zlib-0.5.4.2-2.n-x86_64.pkg.tar.xz add <next x-rev> --> haskell-zlib-0.5.4.2-1.-x86_64.pkg.tar.xz add <next ver>, xrev == 0 --> haskell-zlib-<next ver>-1-x86_64.pkg.tar.xz As you see, if the release is put before the x-rev and the release number is reset on add, then we end up going backwards in version numbers. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus The results point out the fragility of programmer expertise: advanced programmers have strong expectations about what programs should look like, and when those expectations are violated--in seemingly innocuous ways--their performance drops drastically. -- Elliot Soloway and Kate Ehrlich

Nicola Squartini

3:41 a.m.

New subject: Fwd: RFQ: Proposal for new versioning of packages

Got it. Thanks for the clarification. On Fri, May 1, 2015 at 3:42 PM, Magnus Therning wrote:

...

...
Release numbers would still be reset on adding:

xrev == 0 --> haskell-zlib-0.5.4.2-76-x86_64.pkg.tar.xz add xrev == n && n > 0 --> haskell-zlib-0.5.4.2-1.n-x86_64.pkg.tar.xz add <next ver>, xrev == 0 -->haskell-zlib-<next ver>-1-x86_64.pkg.tar.xz

The only concern that I have with your versioning is that having 0.x in

On Thu, Apr 30, 2015 at 07:07:48PM +0900, Nicola Squartini wrote: the

...
release number might suggest that the package is still in a testing stage. And I make xrev == 0 first class (not adding the ".n") because I believe Hackage revisions are ugly and should not exist. Anyway, whatever scheme you choose it's good for me :)

It's addition after bump of x-revision that I worry about:

xrev == 0 --> haskell-zlib-0.5.4.2-76-x86_64.pkg.tar.xz add xrev == n && n > 0 --> haskell-zlib-0.5.4.2-1.n-x86_64.pkg.tar.xz rebuild --> haskell-zlib-0.5.4.2-2.n-x86_64.pkg.tar.xz add <next x-rev> --> haskell-zlib-0.5.4.2-1.-x86_64.pkg.tar.xz add <next ver>, xrev == 0 --> haskell-zlib-<next ver>-1-x86_64.pkg.tar.xz

As you see, if the release is put before the x-rev and the release number is reset on add, then we end up going backwards in version numbers.

/M

-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus

The results point out the fragility of programmer expertise: advanced programmers have strong expectations about what programs should look like, and when those expectations are violated--in seemingly innocuous ways--their performance drops drastically. -- Elliot Soloway and Kate Ehrlich

_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/arch-haskell

3672

Age (days ago)

3673

Last active (days ago)

List overview

Download

4 comments

2 participants

participants (2)

Magnus Therning
Nicola Squartini