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
Attachment:
pgp7LFAUu1QZL.pgp
Description: OpenPGP digital signature