On 20 June 2017 at 02:49, Przemek Klosowski <przemek.klosowski@xxxxxxxx> 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@xxxxxxxxx | Brisbane, Australia _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
