[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
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
filevercmp.h
Description: Text Data
- Re: willing to contribute verrevcmp to gnulib?, (continued)
- Re: willing to contribute verrevcmp to gnulib?, Ian Jackson, 2008/09/29
- Re: willing to contribute verrevcmp to gnulib?, Jim Meyering, 2008/09/29
- Re: willing to contribute verrevcmp to gnulib?, Ian Jackson, 2008/09/29
- Re: willing to contribute verrevcmp to gnulib?, Jim Meyering, 2008/09/29
- Re: willing to contribute verrevcmp to gnulib?, Ian Jackson, 2008/09/30
- Re: willing to contribute verrevcmp to gnulib?, Ian Jackson, 2008/09/29
- Re: willing to contribute verrevcmp to gnulib?, Ian Jackson, 2008/09/29
- Re: willing to contribute verrevcmp to gnulib?, Kamil Dudka, 2008/09/29
- Re: willing to contribute verrevcmp to gnulib?, Ian Jackson, 2008/09/30
- Re: willing to contribute verrevcmp to gnulib?, Ian Jackson, 2008/09/30
- Re: willing to contribute verrevcmp to gnulib?,
Kamil Dudka <=
- Re: willing to contribute verrevcmp to gnulib?, Ian Jackson, 2008/09/29
- Re: Issue with ls -v / sort -V and strverscmp() usage, Jim Meyering, 2008/09/22
- Re: Issue with ls -v / sort -V and strverscmp() usage, Eric Blake, 2008/09/22
- Re: Issue with ls -v / sort -V and strverscmp() usage, Kamil Dudka, 2008/09/22
Re: Issue with ls -v / sort -V and strverscmp() usage, Bruce Korb, 2008/09/21