On Jun 18, 2014, at 04:39 PM, Piotr Ożarowski wrote: >policy mentions that Python 2.X and Python 3.X are separate languages >for us and that's why we have python-foo and python3-foo packages. >I don't want APT to install python3 when I install python-foo and I >don't want APT to install python when I install python3-foo. > >If you want one package to provide Python 2.X and Python 3.X code - it's >fine, just don't use "python-" or "python3-" prefix in package name and >don't provide public libraries.
I agree with what you said, but it's not the point. :)
Take a package like virtualenv. Its library is compatible with both Python 2
and Python 3, plus it provides a command line executable, /usr/bin/virtualenv.
It is set in policy and uncontroversial that the Python 2 version of the
library should be put in the python-virtualenv binary package. Likewise for
the Python 3 version of the library going into python3-virtualenv.
Policy does not specify, afaict, what the binary package name should be that
contains /usr/bin/virtualenv. When compatible, we generally now prefer
executables to be shebang /usr/bin/python3. Clearly, neither
python-virtualenv nor python3-virtualenv are the appropriate binary packages
to contain /usr/bin/virtualenv (and its manpage). python-virtualenv is
clearly inappropriate because it's Python 2, and python3-virtualenv is
inappropriate because especially in a bilingual package, it should only
contain the libraries.
Note in that case that historically, python-virtualenv also contained the
executable, and I resolved the issue by adding a `virtualenv` binary package,
putting the executable and manpage in there.
However, let's take application Foo written in Python 3, with a /usr/bin/foo
executable. But let's say it either doesn't have a Python 2 compatible
library, or it doesn't have any library it generally expects to be imported,
so there are no appropriate python{,3}-foo binary packages. Since we want
dh_python3 to do the right thing with its support code anyway, some questions
come to mind:
* What should its binary package name be?
* What tools should we use to build it?
* How do we tell those tools to install everything in the right place?
Often, such applications are put in a python-foo binary package. Now, I think
that's historically wrong because it clashes with what policy now says
python-foo should be, i.e. the Python 2 version of the library. python3-foo
doesn't seem right either, so I'm suggesting that Debian Python Policy (DPP)
recommend or require that the application go in binary package 'foo' *without*
a python- or python3- prefix. If 'foo' clashes with other binary packages in
the archive, then it must be disambiguated, but DPP should prohibit using
"python-" or "python3-" as a prefix in that case. E.g. maybe call it
'foo-python' (this is where we need a decision!)
I think you still want to use pybuild and dh_python3 for the Python 3
application "foo", which is why I favor the latter doing its manipulations
when binary package "foo" or "foo-python" or "foo-application" Depends on
${python3:Depends}, which I think you're also agreeing with.
So really, all we need to do (in addition to resolving this bug :) is to make
it clear the DPP prohibits applications from being put in the python-foo
binary package, *especially* if it's a Python 3 application.
signature.asc
Description: PGP signature
