This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH 1/3] Compare package versions, not setup.ini timestamps
On Sun, Nov 07, 2010 at 03:45:31PM +0000, Jon TURNEY wrote:
>On 06/11/2010 17:52, Christopher Faylor wrote:
>> On Sat, Nov 06, 2010 at 05:05:13PM +0000, Jon TURNEY wrote:
>>> Currently, when two mirrors offer different versions of a package for a stability
>>> level, the one from the setup.ini with the latest timestamp is chosen. This works
>>> adequately when the mirrors are exactly that, so the one which has been updated most
>>> recently has the most up-to-date version for all packages. But this makes it difficult
>>> to have an overlay, a site which offers updated versions of a subset of packages,
>>> as there's no way to reliably ensure setup selects those updated versions (without
>>> massaging the timestamps in the setup.ini files after downloading them)
>>> So, instead of comparing the setup.ini timestamps, compare the package version numbers
>>> to determine which package is most recent.
>>> This shouldn't change the current behaviour in the simple case where only one mirror
>>> is selected (provided no packages have negative version numbers).
>> I'm not against this idea but I'd like to see what others think about
>I agree that this kind of change needs some careful consideration.
>> I know that cygwinports and other sites use setup.exe for their own
>> purposes but setup.exe was never really intended (Red Hat itself not
>> withstanding) to be used as anything other than a mechanism for
>> installing the cygwin distribution. So, while, again, I am not against
>> this idea, I'd like to see what others think about this. It doesn't
>> seem like we'd lose any functionality if we adopted this change but I
>> may be missing something.
>I hope by inspection of the change to IniDBBuilderPackage.cc, it's not too
>hard to satisfy yourself that the change should make no difference when a
>single mirror is selected: while parsing setup.ini, instead of comparing the
>timestamp against 0, we will be comparing against version "0-0" to see if a
>package version should be used at a given trust level, the answer is still
>As I mentioned before, you are losing the functionality of using negative
>version numbers. :-) If anyone actually cared, this is probably fixable at the
>cost of some complexity in the version number parser and comparator :-)
>I don't think there is any other reduction in functionality.
It looks like there are no objections to this patch, so please check it in.