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 >> this. > >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 >always 'yes'. > >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. Thanks. cgf
