#1 Fix ambiguous Python 2 dependency declarations
Merged 4 years ago by pbrobinson. Opened 4 years ago by ishcherb.
rpms/ ishcherb/adapt pyambiguous  into  master

file modified
+7 -3
@@ -3,7 +3,7 @@ 

  

  Name:           adapt

  Version:        0.3.0

- Release:        2%{?dist}

+ Release:        3%{?dist}

  Summary:        Mycroft's Adapt Intent Parser

  

  License:        LGPLv3
@@ -15,13 +15,13 @@ 

  BuildRequires:  pulseaudio-libs-devel

  BuildRequires:  python2-devel

  BuildRequires:  python2-setuptools

- BuildRequires:  python-six

+ BuildRequires:  python2-six

  BuildRequires:  python3-devel

  BuildRequires:  python3-setuptools

  BuildRequires:  python3-six

  

  %if 0%{?with_tests}

- BuildRequires:  python-pep8

+ BuildRequires:  python2-pep8

  BuildRequires:  python3-pep8

  %endif

  
@@ -79,6 +79,10 @@ 

  %{python3_sitelib}/%{name}/

  

  %changelog

+ * Mon Dec 11 2017 Iryna Shcherbina <ishcherb@redhat.com> - 0.3.0-3

+ - Fix ambiguous Python 2 dependency declarations

+   (See https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3)

+ 

  * Wed Jul 26 2017 Fedora Release Engineering <releng@fedoraproject.org> - 0.3.0-2

  - Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild

  

This package uses names with ambiguous python- prefix in requirements.

According to Fedora Packaging guidelines for Python, packages must use names with either python2- or python3- prefix in requirements where available.
We are aiming to rename python-* dependencies to python2-*, so we can later switch the python-* namespace to Python 3.

This PR is part of Fedora's Switch to Python 3 effort.

Note that, although this PR was created automatically, we will respond to any comments or issues which you might find with it. We will keep the PR open for review for a week, and if there's no feedback we'll merge it.

Koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=23642917
Note: please do not backport this to f26 branch(es) as some of the modified requirements are not available there

This PR was opened automatically, for source code see here

They weren't ambiguous when the package was created, those dependencies didn't exist at that time, the changelog should just read "update python packages to new python2 packaging standards" as 'ambiguous' reads as if the packager explicitly did something wrong!

Pull-Request has been merged by pbrobinson

4 years ago

Oh, and on the " Note: please do not backport this to f26 branch(es) as some of the modified requirements are not available there" component..... that should be fixed, I'm not maintaining packages with if/else that I have to manually track!

They weren't ambiguous when the package was created, those dependencies didn't exist at that time, the changelog should just read "update python packages to new python2 packaging standards" as 'ambiguous' reads as if the packager explicitly did something wrong!

Thank you for the feedback. I tent to agree with you and will change the wording of the changelog to something less insulting.

Oh, and on the " Note: please do not backport this to f26 branch(es) as some of the modified requirements are not available there" component..... that should be fixed, I'm not maintaining packages with if/else that I have to manually track!

I am not sure I understand how this is supposed to be fixed. This is just a note for those packagers, who usually cherrypick commits to previous Fedora branches. I deliberately did not add if/else statements for cases like this in the spec file, because these PRs target Rawhide branch.

I am not sure I understand how this is supposed to be fixed. This is just a note for those packagers, who usually cherrypick commits to previous Fedora branches. I deliberately did not add if/else statements for cases like this in the spec file, because these PRs target Rawhide branch.

The problem is that if people just push to all branches, and many do, they'll end up with broken packages.

The problem is that if people just push to all branches, and many do, they'll end up with broken packages.

That is the reason that just the note alert is added to the PR description, so that people are aware of the risk if they push to all branches. But adding if/else statements for those cases is already up to the packagers. Feel free to correct me if I am wrong, or suggest how we can handle this in a better way.

@pbrobinson Fedora evolves. Things change. As a packager you basically have two options:

  1. let the rawhide/master branch move forward and only backport specific changes to the older branches
  2. use if/else statements in you specfile and maintain a single version of it

We think the first option is more general and in line with the Updates Policy. That's why we don't add the if/else statements and only mention the fact that this is not compatible with f26, f27.

However, so you don't say we are making you packaging unbearable, I've looked at those packages. python2-six is available in F26. python2-pep8 is not, but the change is rather trivial, so I'm building it for you just now. Except an update shortly. Note that in some cases, the change is not that trivial and this will not always be possible.

Edit:

@churchyard no shit, I'm well aware of how Fedora evolves, I've been involved for decades.... please don't explain to me how to suck eggs.....

I don't generally push things to older releases, I have better things to do, but having been in rel-eng and other stuff people do just push to all releases, so it IS and will be a problem. I've seen people push mass rebuild package bumps to stable releases as updates which have ZERO change.... so please come to with actual details that are relevant!

You've been involved for decades, so I guess you should be aware of the Fedora Code of Conduct. No need for shits and sucks, thank you very much.