Bug#799268: RFS: ck/1.6.2 [ITP]
On 18/09/15 at 12:25 +0200, Grigori Fursin wrote:
> Hi Lucas,
>
> Thank you very much for your time to check it - really appreciated!
> And sorry for some mix ups - it's my first time trying to package
> something for Debian ;) ...
>
> >Must be fixed:
> -> Given that this software is not specific to Debian, and publishes
> >releases on its homepage, this should not be a native package. instead,
> >its version should be of the form 1.6.2-1, 1.6.2-2, so that the Debian
> >revision (the part after the '-') can be changed when packaging changes
> >are made, without making a new upstream release.
>
> Oh, I see. I will check how to fix that ...
>
> >- I'm not familiar with python packaging, but when building this
> >package, I only get a python2 package (and no python3 package). There's
> >something wrong here. I wonder if it's related to the fact that the
> >version of python-stdeb that you seem to be using (according to the
> >headers in say debian/rules) is very old. Given that Debian packages are
> >uploaded targetting Debian 'unstable', it's better to do Debian
> >development in unstable or testing (possibly in a chroot).
>
> I created a separate package for python3-ck but it's true that it
> doesn't look like it was uploaded - need to check that ...
>
> >Should probably be fixed:
> >- If I understand ck correctly, it's more an application than a library:
> >users are not really exposed to the fact that it's written in python,
> >and the python lib is not supposed to be used by third parties (it can
> >be used in ipython, but the target is not really to build a third party
> >application on top of it).
> >If that's correct, then it should not be packaged like a python library,
> >but more like an application (that happens to be written in python).
>
> In fact, it is both. It can be used as a standalone python library or it can
> be used as an application (via ck batch script).
Then you might want to package the application separately, so that the
library packages are really libraries.
> >- there's another problem: namespace pollution in few-characters
> >commands. It's usually a bad practice to name something (that is not a
> >historical unix tool) with 1 or 2 letters only.
>
> Oh, I didn't know that :( . Will it really be a problem (I didn't see any
> tool called ck yet)? The problem is that our users now share some artifacts
> in this format and they use this name (in scripts or internal calls),
> so changing this name now will be a nightmare :( ...
I'm not sure if there's an official policy about that. It's probably
worth trying to upload with a ck binary, and see if someone complains :)
Lucas
Reply to: