https://bugzilla.redhat.com/show_bug.cgi?id=1393129 Stephen Gallagher <sgallagh@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(mmathesi@redhat.c | |om) --- Comment #3 from Stephen Gallagher <sgallagh@xxxxxxxxxx> --- (In reply to Merlin Mathesius from comment #2) > Thank you for the detailed and helpful review comments. > > The selected commit and version (1.2.0) were unofficial in upstream. > However, an official tag for that commit was added just today > (https://github.com/autotest/aexpect/issues/14). > > I believe I addressed all of your other issues. I also attempted to include > support for both Python 2 and Python 3. The tagged version 1.2.0 of aexpect > does not support Python 3--although the current HEAD does. The upstream > maintainers have suggested a version 1.3.0 will be coming soon. Thus, in the > interim, I updated the package version to 1.2.1, set the source to use the > current HEAD commit, and included a patch to update the version string > embedded in setup.py. You can't do this. It's not safe to name something 1.2.1 because upstream could eventually opt to release a 1.2.1 that is entirely different from what you called 1.2.1. Then users of this package will be confused. Please drop the version hack. If you want to release with the python 3 support, you need to follow the naming guidelines at https://fedoraproject.org/wiki/Packaging:Versioning#Snapshot_packages The result will end up looking like: aexpect-1.2.0-1.20161109git%{shortcommit0}.fc26 > > New Spec URL: https://merlinm.fedorapeople.org/aexpect-1.2.1.spec > New SRPM URL: https://merlinm.fedorapeople.org/aexpect-1.2.1-1.fc24.src.rpm > New Koji scratch build URL: > http://koji.fedoraproject.org/koji/taskinfo?taskID=16378886 OK, a few more comments: 1) I should have thought of this earlier, but aexpect-helper is probably important to operation. So we should ship a version of it in the python3 subpackage, renamed to python3-aexpect-helper (at least until the support becomes stable). It probably wouldn't be a bad idea to rename the python2 version to python2-aexpect-helper and carry a symlink for the /usr/bin/aexpect-helper name. This would be future-compatible whenever we decided to swap over to python 3 as the preferred version. If this is getting too complicated, feel free to skip Python 3 support entirely for the first pass here. It can be a quagmire. 2) The master name of the package should be python-aexpect, not just aexpect. The subpackages it produces are correct. 3) The order you run the %py2_install and %py3_install macros matters. Because both builds provide /usr/bin/aexpect-helper, whichever one builds second will overwrite the one that builds first. In this case, that means that you are actually installing the Python 3 version of the binary into the python2-aexpect subpackage. Oops! (If you follow my symlink suggestion in 1), you'll want to do the rename between the %py2_install and %py3_install calls and create the symlink last.) -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx