[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: willing to contribute verrevcmp to gnulib?

From: Kamil Dudka
Subject: Re: willing to contribute verrevcmp to gnulib?
Date: Tue, 30 Sep 2008 14:54:27 +0200
User-agent: KMail/1.9.9

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 

> 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,    

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-
>   alice_1.63-2.dsc                    linux-
>   alice_1.63-2.diff.gz                        linux-
>                                       linux-
> ?
In this example, there is no problem - all tested implementation (rpm, dpkg, 
glibc and filevercmp) give the same order:

> which is for alice perhaps not ideal but your algorithm does this
>   alice_1.63-2.diff .gz               and     linux- .bz2
>   alice_1.63-2 .dsc                   linux- .gz2
>   alice_1.63.orig.tar .gz             linux- .sign
>                                       linux- .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- .tar.bz2
  alice_1.63-2 .dsc                     linux- .tar.gz2
  alice_1.63 .orig.tar.gz               linux- .tar.bz2.sign
                                        linux- .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 


Attachment: filevercmp.h
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]