Livecheck and the github port group

[Rainer Müller]

On 2012-11-17 21:35, Sean Farley wrote:
> On Sat, Nov 17, 2012 at 2:18 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>>
>> On Nov 17, 2012, at 12:31, Sean Farley <sean.michael.farley at gmail.com> wrote:
>>
>>> This is another example of the internal macports comparison code not
>>> recognizing release candidates. Is there any reason to not fix that
>>> (backwards compatibility?)?
>>
>> How do you propose to fix it? I assume we're talking about making changes to the vercmp procedure, but what changes exactly?
> 
> Basically, I was thinking of following the algorithm described for
> parse_version:
> 
> http://packages.python.org/distribute/pkg_resources.html#parsing-utilities

The version comparison scheme we are using originates from an earlier
version of RPM. For example described at [1]. For experiments with our
current algorithm, Ryan wrote a script that just compares two version
numbers and presents the result [2].

The algorithm described in the source above might work for python but is
not a universal solution. Quoting the document:

  The algorithm assumes that strings like “-” and any alpha string
  that alphabetically follows “final” represents a “patch level”.

Just think of the version numbers used for openssl such as 0.9.8g
(greater than "final") and 1.0.1c (less than "final"). We would have to
use a different representation of the version number for the port to get
things right.

Also note that for python, there are different version comparison
algorithms used for the packages distutils and distribute.

Take a look at the version numbers for py-matplotlib alone [3]. There is
no unified representation used across the versions in upstream:
  v1.2.0rc1
  v1.1.0-rc1
  v0.99.0.rc1

The parse_version algorithm would not work on all of them correctly
("Dots are dropped, but dashes are retained.").

> This would fix so many wrong version comparisons that are due to
> '1.0-rc', '3.0-1', etc. ... but I usually try to avoid the deep
> internals of macports since it's all in tcl :-P

The version comparison is in the pextlib package that is actually
written in C [4].

There are many possible ways to format a version number and we already
experienced the problems with the perl floating point numbers in the past.

Regarding extending the versioning scheme, I could imagine the addition
the '~' extension [5] in order to add a way to specify a version number
for a pre-release that is considered to be less than the final release
number (e.g. 1.0~rc3 < 1.0). This would reduce the number of reasons for
which the epoch number needs to be increased in ports; this is
especially important for *-devel ports.

However, this would only change the way the version number is compared
internally. If the upstream website uses a different format to represent
the version number, there is no easy way to automatically translate
between them.

So for now, you need to use a more strict livecheck.regex that excludes
release candidates and beta versions.

Rainer

[1] https://fedoraproject.org/wiki/Archive:Tools/RPM/VersionComparison
[2] https://trac.macports.org/browser/users/ryandesign/scripts/vercmp
[3] https://github.com/matplotlib/matplotlib/tags
[4] https://trac.macports.org/browser/trunk/base/src/pextlib1.0/vercomp.c
[5] http://rpm.org/ticket/56