On 20 June 2017 at 02:49, Przemek Klosowski <przemek.klosowski(a)nist.gov> wrote:
On 06/19/2017 10:50 AM, Iryna Shcherbina wrote:
The reason behind the second change is that there are a lot of Python 2 only
packages having `python-xxx` in Requires, which will start pulling Python 3
dependencies when we switch to Python 3 as default. This will most possibly
cause a number of unexpected issues, which is what we are trying to avoid.
If you expect your package to work when we switch to Python 3 as default,
then you should already switch it to Python 3 or provide a Python 3
subpackage and depend on `python3-xxx`.
It seems to me that there are two kinds of Python packages affected by this
issue: some track the evolution of the ecosystem and make sure they work
with both Python 2 and 3, while the others assume a specific environment,
and expect the user to conform to that. What I dislike about this proposal
is that it imposes on the first kind: their package name needs to change,
presumably to 'pyton3-xxx' even though the package might work with python2
as well. This sounds like penalizing the good behavior.
It's also an annoyingly difficult policy to comply with for anyone
attempting to maintain RHEL/CentOS/EPEL compatible packages that will
use Py2 in those contexts and Py3 in Fedora.
So I think there needs to be a way for packages to indicate that they
genuinely don't care whether their dependencies are the Python 2
version or the Python 3 version for dependencies that either offer
both in Fedora, or else offer Py3 in a Fedora context and Py2 in
RHEL/CentOS/EPEL.
Looking at
https://fedoraproject.org/wiki/Packaging:Python#Dependencies,
I think the first paragraph provides that marker: if a package has
"BuildRequires: python3-devel" *without* "BuildRequires:
python2-devel", then it should be allowed to continue using the
unqualified markers for the rest of its Python dependencies.
Whereas if a package has "BuildRequires: python2-devel" defined in
Fedora, then it needs to start being explicit about those Python 2
dependencies. Essentially, Python 3 switches from being opt-in (as it
has been to date) to being opt-out.
The difference between that and the current policy wording is that it
would mean that package maintainers for upstreams that have been
keeping up with their Python 3 compatibility checking only need to
change one thing (i.e. switching their build dependency to Python 3
rather than Python 2), rather than everything. The only folks that
would need to make sweeping changes to their dependency declarations
are those whose packages genuinely can't run on Python 3 yet.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia