On Tuesday 30 September 2008 12:13:08 Ian Jackson wrote: > Sorry, I overlooked this message before. Now I'm really confused. > You seem to have already rewritten it. So why are people asking for > permission and/or copyright assignment ? The core of filevercmp module is the verrevcmp function taken from debian's dpkg, there is modified only the signature of verrevcmp to take 2 more parameters - length limits.
> I haven't reviewed your implementation for correctness but I will if > you want me to. Did you base your version on the Debian specification I see you already did. Thanks! > at > http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version > ? It is not based on any specification. The verrevcmp function is used as is. Moreover there is a sort of wrapper to deal with suffixes. > > > /* > > TODO: copyright? > > Who actually wrote that code ? The most part of current filevercmp module is written by me, but there were a lot of suggestion here on the list. So it is not only my own work, don't worry :-) > Actually, looking at it it seems to have been created by copying and > pasting Anthony Towns's verrevcmp and reformatting it ! > > This is surely a ridiculous approach. What if it needs to be extended > or modified in the future ? You won't be able to just apply patches > from dpkg. Reformatting code just for the sake of it is always wrong. This function is designed to be distribution independent. Before writing the filevercmp module I did some investigation of known version sort algorithms (rpm, dpkg, glibc and its modifications) to choose the best one for gnulib. I don't think gnulib should follow some distribution related patches. The behavior of fundamental utilities like ls and sort should be stable for a long time. As for the indentation, gnulib uses GNU indentation style, not my own choice... > NB that this is a technical objection. I'm sure that Anthony Towns, > just like any member of the Free Software world, would not try to use > copyright law to prevent someone from making stupid modifications to > their code. > > > On to a more useful conversation: > > Can you explain in some more detail why you took the approach that you > did for file extensions ? I'm not sure I understand the specific > effect. Is it exactly equivalent to adjusting the lexical value of > the rightmost `.' in each string to be just greater than `~' ? The file extension is defined as regular expression (\.[A-Za-z][A-Za-z0-9]*)*$ (full match). The approach is explained in the filevercmp.h (forgot to attach, attaching now): This function compares strings, in a way that if VER1 and VER2 are version numbers and PREFIX and SUFFIX (SUFFIX defined as (\.[A-Za-z][A-Za-z0-9]*)*) are strings then VER1 < VER2 implies filevercmp (PREFIX VER1 SUFFIX, PREFIX VER2 SUFFIX) < 0. Shortly: The result of filevercmp is always the same, not matter if there is a file extension or not. > What about filenames like > alice_1.63.orig.tar.gz or linux-2.6.16.21.tar.bz2 > alice_1.63-2.dsc linux-2.6.16.21.tar.bz2.sign > alice_1.63-2.diff.gz linux-2.6.16.21.tar.gz > linux-2.6.16.21.tar.gz.sign > ? In this example, there is no problem - all tested implementation (rpm, dpkg, glibc and filevercmp) give the same order: alice_1.63-2.diff.gz alice_1.63-2.dsc alice_1.63.orig.tar.gz linux-2.6.16.21.tar.bz2 linux-2.6.16.21.tar.bz2.sign linux-2.6.16.21.tar.gz linux-2.6.16.21.tar.gz.sign > which is for alice perhaps not ideal but your algorithm does this > alice_1.63-2.diff .gz and linux-2.6.16.21.tar .bz2 > alice_1.63-2 .dsc linux-2.6.16.21.tar .gz2 > alice_1.63.orig.tar .gz linux-2.6.16.21.tar.bz2 .sign > linux-2.6.16.21.tar.gz .sign > which is just bizarre (spaces put in to show the cut point) > and in the RHS leads to odd results. It will be divided like this: alice_1.63-2 .diff.gz and linux-2.6.16.21 .tar.bz2 alice_1.63-2 .dsc linux-2.6.16.21 .tar.gz2 alice_1.63 .orig.tar.gz linux-2.6.16.21 .tar.bz2.sign linux-2.6.16.21 .tar.gz.sign > > So I think this wrinkle may be doing more harm than good. We might be > better off with a simpler algorithm. Nobody has found any harmful example yet. Thanks for review and new information. Kamil
/* TODO: copyright? This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>. */ #ifndef FILEVERCMP_H #define FILEVERCMP_H /* Compare version strings: This function compares strings S1 and S2: 1) By PREFIX in the same way as strcmp. 2) Then by VERSION (most similarly to version compare of Debian's dpkg). Leading zeros in version numbers are ignored. 3) If both (PREFIX and VERSION) are equal, strcmp function is used for comparison. So this function can return 0 if (and only if) strings S1 and S2 are identical. It returns number >0 for S1 > S2, 0 for S1 == S2 and number <0 for S1 < S2. This function compares strings, in a way that if VER1 and VER2 are version numbers and PREFIX and SUFFIX (SUFFIX defined as (\.[A-Za-z][A-Za-z0-9]*)*) are strings then VER1 < VER2 implies filevercmp (PREFIX VER1 SUFFIX, PREFIX VER2 SUFFIX) < 0. This function is intended to be a replacement for strverscmp. */ int filevercmp (const char *s1, const char *s2); #endif /* FILEVERCMP_H */
