On Thu, Jan 29, 2015 at 05:28:37AM -0500, Bohuslav Kabrda wrote:
----- Original Message -----
> On Wed, Jan 28, 2015 at 11:09:08AM -0500, Bohuslav Kabrda wrote:
> > Some general notes:
> > If your package depends on Python because of a Python script that has
> > /usr/bin/python in hashbang, you need to change this to /usr/bin/python3.
> > All "Requires" and "BuildRequires" on Python extension
modules have to be
> > changed from "python-foo" to "python3-foo" in order for
this change to
> > work.
>
> Wouldn't it be better to simply say that "Dependencies have to be adjusted
> so provide the necessary Python 3 modules." ? How to do it depends on the
> package,
> sometimes a slightly different set might be used, and simply changing all
> python-
> to python3- might not be enough.
As I noted, this bug is not supposed to be created for "libraries" (i.e.
packages that have python- or python3- subpackages), but for "applications" (for
example "bind", that has some Python scripts in it, but no Python bindings or
importable modules). (Either that answers your question, or I didn't understand the
question in which case please try to rephrase it :))
Let's try with an example. Let's say I have some application which
uses python2 and systemd-python. To have it use python3 instead, I have
to change the she-bang, and Requires:systemd-python to Requires:systemd-python3.
Your text does not cover this, because it only talks about packages which
have "python" as a prefix.
As a second example, let's say my hypothetical app uses python-subprocess32,
a backport of Python 3 functionality for Python 2. The dependency would
be updated by simply removing it.
It's hard to provide a general recipe, but packagers usually know what they
are doing, and a general reminder should be enough.
> > If your package is an "application" (let's
call it "foo") and it also
> > generates a subpackage with Python bindings (i.e. "python-foo" or
> > "foo-python"), you should provide a python3 subpackage
("python3-foo" or
> > "foo-python3") and use that as dependency of other subpackages.
>
> This part is unclear. What "other subpackages" and why should the
> depend on the python3 subpackge?
To explain it on an example: there's python-dnf and python3-dnf and dnf - all are
subpackages generated from a single srpm. Right now, dnf requires python-dnf, but should
be switched to require python3-dnf (and all other subpackages generated from dnf.srpm
should be switched to require python3-dnf). Does that make it clearer? (I could add this
example to the bug description)
This would be helpful.
Zbyszek