[Debian-med-packaging] Some questions about seq (Was: r11551 - in trunk/packages/seg/trunk/debian: . patches source)

[Andreas Tille]

On Thu, Jul 05, 2012 at 02:09:38PM +0200, Laszlo Kajan wrote:
> > 1. At some point in time there was a decision to choose a name
> >    longer than only three letters (which is a bit weak regarding
> >    potential name space pollution.
> > 
> >    I do not question your decision in principle but it would nice
> >    to hear the motivation behind this step.
> 
> Ok, I totally understand. I did not know about the >3-letter-policy. But SEG is and old and well established tool, so I had the idea of not
> renaming it.

There is no real policy about >3-letter but we just had a similar
discussion recently (on debian-devel??) that such names are quite
generic and should be avoided if possible.
 
> BUT! I am not attached to the name particularly: what name do you (or Team) suggest? We used to call this 'lowcompseg' at one point.

This somehow sounded more reasonable to me.  Without having checked
before my gut feeling was correct - we just have such a tool:

$ apt-file search /usr/bin/seq | grep "seq$"
coreutils: /usr/bin/seq

  --> man seq

So this name is obviosely a really bad choice and if you once settled
with lowcompseg this sounds quite reasonable wo me.

I have seen that you did contacted the author.  I would add the remark
about a name space pollution with a quite basic tool and once he might
accept your patches I'd suggest some real versioning.

> > 2. I agree that versioning unversioned code is hard.  You decreased
> >    the version number compared to the former choice and I also
> >    wonder why.  Looking at the ftp download site the youngest file
> >    is dated
> > 
> >      genwin.h	3.5 kB	6/20/00 2:00:00 AM
> > 
> >    So I would expect a versioning 20002006 rather than 199<something>.
> >    Same as above:  You might have your reasons I do not question but
> >    a short explanation might help letting other people know.
> > 
> >    Remark: I personally always use 0.0.YYYYMMDD version numbers if
> >    there is some need to invent a date based version to be easily
> >    able to increase the version once upstream might decide to switch
> >    to real version numbers.  I admit in this case chances are low that
> >    this will ever happen - I'm just mentioning it as some general
> >    information.
> 
> Indeed I considered looking at the youngest file but then decided to use the date of the newest record in the README file upstream seems to use
> as change log.
> 
> Ok, so Andreas, I can not do better than I already have, I gave my best shot at the name and the version. I am not attached to either, so choose
> (or someone from the Team) a better one if you can. Or tell me (or Team) what it should be, I can change it and then let you upload.

I do not want to put my versioning policy on to you but if you are
actually asking I would vote for 0.0.20000620 (above I did mixed up
month and day).
 
> So can someone choose a name for the package?

lowcompseg
 
Kind regards

      Andreas. 

-- 
http://fam-tille.de