> No, the RPM version compare algorithm is very simple, and well > documented. It does the best it can given that is has to handle all the > different versioning schemes used by different programs with a single > function. It gets it "right" probably >90% of the time. > > The challenge is that if you were to ask whether 1.001 and 1.1 are equal > the answer is no when comparing them as floating point numbers. > However, 1.1 and 1.10 are the same thing if you compare as floating > point numbers, but, in many versioning schemes they are different, and > similarly 1.101 and 1.1005 are ambiguous as to how they compare. > > So, no this isn't a bug, nor is it broken-by-design. If you can come up > with an algorithm that does a better job and is as fast as the current > one, please post it. The current one is a step above some of the other > algorithms available, but does, as you noted, have some unusual corner > cases. First of all, I completely understand that making generic version handling is probably just not possible. And I understand that my understanding of RPM's internals is very limited. That being said (i.e. caveat emptor), what is the feasibility of containing information in the RPM database (and the RPM itself of course) about how its versions should be checked. If no information was kept then you could fall back to the traditional method (which works for most stuff well). On the other hand if a method was specified, it would use that alternate method. For instance in the case of perl modules (and perl itself), they would specify somehow that the version should be checked as a floating point number. So in the end you end up with a few alternate methods of doing versioning checking. This could be extended further such that a rpm could provide a function that comparies versions (kind of like passing a function to the sort routines that understands how to discern the magnitude of the objects to be sorted). This is a completely rough idea (i.e. there are many details to be worked out), but it seems feasible to the naive (-; Anyway, what do you think (you being anyone that cares)? Cheers...james _______________________________________________ Redhat-devel-list mailing list Redhat-devel-list@redhat.com https://listman.redhat.com/mailman/listinfo/redhat-devel-list
