Bug#799268: RFS: ck/1.6.2 [ITP]
Sure, I will check what can be done.
It's just that we use it much more as app at the moment
then library, so maybe we can just keep it as it for now.
If we will see increasing use as library, we can separate them ...
Thanks again and have a good weekend,
Grigori
-----Original Message-----
From: Lucas Nussbaum
Sent: Friday, September 18, 2015 3:49 PM
To: Grigori Fursin ; 799268@bugs.debian.org
Subject: 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: