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.
