[csw-maintainers] [policy] Re: [csw-pkgsubmissions] newpkgs rdesktop

[Ben Walton]

Excerpts from Peter Bonivart's message of Sat Feb 05 10:44:26 -0500 2011:

Hi Peter,

> [Moved to maintainers since we're again discussing new policy at
> release time while packages are stuck]

Thank you.

> I don't agree, the version string standard is not very well defined
> and if you look in the catalog we have some really ugly ones in
> there.  Doing the compares solely on REV made it possible to get rid
> of the "_rev=foo"-uglyness and move it to the first part
> instead. Introducing new stuff there may break package tools as
> well.

I'm sorry, I wasn't clear on this.  I didn't mean specifically tacking
it on to the end of the REV= portion, but just noting it as part of
the whole version string, of which REV= is a prominent portion.  Now
that both tools use the date stamp in REV= as the primary version
identifier, it would likely be better to place any additional info in
the leading upstream version part.

We could take a page from the RHEL book here and add a
.csw.$localpatchlevel (they use .el5, .el4, etc) or something similar.
That makes it more clear than just tacking on 'patched' to the
existing version string.  $localpatchlevel could monotonically
increase for every local feature/bug patch applied that is not part of
the upstream source and is not a simple portability patch.  When the
upstream version changes, this could (possibly) revert to 0 (drop the
.csw.$localpatchlevel), etc.

> My suggestion is to make it clear that we NEVER have anything after
> the REV (any number of dot separated numerics) and make it up to the
> maintainer to add "p" to the first (version) part if he sees
> fit. That part is not used for version comparison so it's up to the
> maintainer what's in it.

Phil is right that the tools could be updated to handle this extra
info, but I agree that keeping it simpler is better.  Any new package
that adds this info would also have the REV= string, so version
compares would use that and ignore anything in the traditional version
string.  I believe that the comparison rules for this were such that
if one package has REV= and the other doesn't the REV= won by fiat, so
that should cleanly accommodate updating old packages too.

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302