Re: version anomalies

[Jon Turney <jon.turney@dronecode.org.uk>]

I've added replace-versions: annotations in override.hint for the below:

On 31/01/2018 17:58, Jon Turney wrote:
> This finds the following anomalies for x86_64:
[...]
> [a] https://cygwin.com/ml/cygwin/2018-01/msg00204.html

gcc 6.4.0-5 was relabelled as test (now current again since cygwin 2.10.0)

> [b] https://cygwin.com/ml/cygwin-announce/2017-10/msg00021.html

lftp 4.8.0-1 was withdrawn as broken

> [c] https://cygwin.com/ml/cygwin/2016-11/msg00125.html

libproj9 4.9.3-1 was withdrawn as it contains the wrong soversion 
(libproj12 not libproj9)

> [d] https://cygwin.com/ml/cygwin/2017-03/msg00423.html

slang 2.3.1pre17-1 pre-release version should have been something like 
2.3.1-0.1pre17 for correct ordering.

> [e] https://cygwin.com/ml/cygwin-apps/2015-07/msg00099.html

xdelta 3.0.9-1 belongs to xdelta3

> [f] https://cygwin.com/ml/cygwin/2015-03/msg00384.html

socat 2.0.0-b7-1 was relabelled as test

> [g] https://cygwin.com/ml/cygwin/2015-02/msg00555.html

perl_autorebase 001001-1 was a test version

> I've implemented a feature in 2.885 which causes setup to selectively 
> dist-upgrade package versions listed as 'replace-versions:' in 
> setup.ini, so problem versions can be replaced automatically, which 
> seems appropriate for all of these.

and also:

[h] https://cygwin.com/ml/cygwin-apps/2018-01/msg00047.html

libgc1 7.6.2-1 was withdrawn as it contains the wrong soversion (libgc2 
not libgc1)

[i] https://cygwin.com/ml/cygwin-announce/2015-07/msg00054.html

cvs 1.12.13-10 ('feature' release) is older than 1.11.23-1 ('stable' 
release) (x86 only)

> [*] These versions aren't ordered correctly by the version comparison we now define

cscope 15.8.0.1-2 is an error where a single version is out of order

xwinclip 2.0.0 (x86_64 only) is an error where a single version is out 
of order

So, I've also annotated these as replace-versions:

It's increasingly pointless to compensate for mistakes the longer ago 
they were made, so I don't think I'll bother doing anything about even 
older mistakes which only exist in x86...