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
