On Apr 25, 2015, at 03:42 PM, Tomasz Buchert wrote: > * the library provides a program as /usr/bin/pyenigma.py; should I: > (a) declare another binary package (say, pyenigma) with it and > make it depend on python3-enigma or (b) leave it as it is now, a > part of the library? > (a) seems like a more canonical solution, but (b) looks more > practical since I doubt that people will very rarely use pyenigma > on its own
In general, I like creating a separate binary package for the /usr/bin scripts. Call it -cli or -common or -bin or some such. I usually also include a manpage in that package (via help2man at least, if not rst2man). I like this especially if the source package also provides libraries for Python 2 and Python 3, since it seems unnatural to include the /usr/bin script in either of those library packages. And of course, it would depend on python3-enigma <wink>. It's a little more work to do it this way, but I think it makes for cleaner packaging. And if you're already building two binary packages, a third isn't so much extra work. > * lintian complains about .py exntesion in a binary stored in > /usr/bin/; should I absolutely change it to no extension? it's > trivial to do, but the instructions at > https://bitbucket.org/bgneal/enigma/ will be misleading On Apr 25, 2015, at 12:16 PM, Scott Kitterman wrote: >People will have different opinions on this. The point of not having the >language extension on there is so that if something gets re-implemented in a >different language, the name doesn't change. For this particular case, since >being pythonic is part of the point, I think it's not applicable. If it were >me, I'd leave it and override the lintian warning. We already have some cases where we deviate from upstream. coverage/python{,3}-coverage is a frequent example. .py extensions in /usr/bin bug me, but YMMV. If it were me, I'd probably install it without the .py, but it's also fine to install it with the .py. Cheers, -Barry
pgp0kG0wxjPx6.pgp
Description: OpenPGP digital signature
