Thanks for the feedback. I did rewrite this a little bit, so hopefully it's clearer. I left some of the text in there because at least to me it reads better and provides some rationale for why the rules are there. But hey, it's a wiki so please feel free to make further improvements!
Cheers, -Barry On Oct 07, 2015, at 11:34 PM, Piotr Ożarowski wrote: >[Debian Wiki, 2015-10-07] >> https://wiki.debian.org/Python/LibraryStyleGuide?action=diff&rev1=64&rev2=65 >> >> >> == Gotchas == >> >> + === Executables and library packages === >> + >> + Let's say you have a Python package which results in Python 2 and 3 >> libraries, and a Python 3 executable. What is the best practices for naming >> and organizing your binary packages? >> + >> + Clearly you want to have: >> + >> + * python-foo -- the Python 2 library >> + * python3-foo -- the Python 3 library > > * foo -- for the executable (and possible additional dependencies that > library doesn't need) > >maybe extent it to: > > * python-foo -- the Python 2 library (and Python 2.X scripts if they're > Python 2.X specific) > * python3-foo -- the Python 3 library (and Python 3.X scripts if they're > Python 3.X specific) > >> + >> + but where should the `/usr/bin/foo` script go? You could put it in >> `python3-foo` but you '''CANNOT''' put it in `python-foo` or for that matter >> any binary package that starts with the `python-` prefix. `dh_python3` >> refuses to rewrite shebang lines for any executable in a binary package that >> starts with "python-" or "pypy-". This means that something like >> `python-foo-cli` or `python-foo-bin` is unacceptable. > >I'd remove this part - it's not dh_python3 specific (dh_python2 and >dh_pypy does similar things) and I don't think such corner case should >be in style guide > >> + >> + Here are some recommendations. We do not have a standard (though maybe we >> should): >> + >> + * `foo` - this is nice if it parallels the /usr/bin/foo name but it might >> collide with existing packages, and some people don't like to make such a >> claim on an unadorned top level package >> + * `python3-foo-cli` or `python3-foo-bin` - not as nicely discoverable, >> but `command-not-found` can help, and dh_python3 will work > >if someone creates python3-foo-cli binary just to ship /usr/bin/foo it >might as well be foo (if there are no /usr/bin/foo name collisions, >binary package name should be safe as well) so I'd remove it
Description: OpenPGP digital signature