https://github.com/ignatenkobrain/fedora-packages/blob/master/python-uritemplate/python-uritemplate.spec This is my spec file. In short: %global modname uritemplate %global altname uritemplate.py %package -n python2-%{modname} %python_provide python2-%{modname} %python_provide python2-%{altname} %package -n python3-%{modname} %python_provide python3-%{modname} %python_provide python3-%{altname} But after building I see following: [brain@x1carbon python-github3py]$ sudo dnf repoquery --provides python2-uritemplate Last metadata expiration check: 0:08:37 ago on Wed Jun 29 12:13:22 2016. python-uritemplate = 0.3.0-1.fc25 python-uritemplate.py = 0.3.0-1.fc25 python2-uritemplate = 0.3.0-1.fc25 python2.7dist(uritemplate.py) = 0.3.0 [brain@x1carbon python-github3py]$ sudo dnf repoquery --obsoletes python2-uritemplate Last metadata expiration check: 0:12:37 ago on Wed Jun 29 12:13:22 2016. python-uritemplate < 0.3.0-1.fc25 python-uritemplate.py < 0.3.0-1.fc25 [brain@x1carbon python-github3py]$ sudo dnf repoquery --provides python3-uritemplate Last metadata expiration check: 0:08:31 ago on Wed Jun 29 12:13:22 2016. python3-uritemplate = 0.3.0-1.fc25 python3.5dist(uritemplate.py) = 0.3.0 [brain@x1carbon python-github3py]$ sudo dnf repoquery --obsoletes python3-uritemplate Last metadata expiration check: 0:12:48 ago on Wed Jun 29 12:13:22 2016. No Provides: python2-uritemplate.py in python2 subpkg No Provides: python3-uritemplate.py in python3 subpkg No Obsoletes for python3-uritemplate.py in python3 subpkg I guess it's because of "." in %{altname}.
Why do you need to provide "python2-uritemplate.py" and "python3-uritemplate.py"? %python_provide is intended for module names; "uritemplate.py" is not a module (i.e. something you can import).
(In reply to Petr Viktorin from comment #1) > Why do you need to provide "python2-uritemplate.py" and > "python3-uritemplate.py"? %python_provide is intended for module names; > "uritemplate.py" is not a module (i.e. something you can import). it's upstream project name and same is for PyPI. pip install uritemplate.py works, so I wanted to have python3-uritemplate.py provides for users/developers which will not find that python3-uritemplate provides that subpackage. Is this understandable?
(In reply to Petr Viktorin from comment #1) > Why do you need to provide "python2-uritemplate.py" and > "python3-uritemplate.py"? %python_provide is intended for module names; > "uritemplate.py" is not a module (i.e. something you can import). also sometimes there is packages like: python-requests-toolbelt. when you do import you should use requests_toolbelt, so that package should provide with dash and with underscore. It's also broken.
Actually, what you import, has nothing to do with this. This is simply made so that python2-blah also provides python-blah. python2-uritemplate should provide python-uritemplate, not python-uritemplate.py. For provides with names on PyPI, see https://fedoraproject.org/wiki/Changes/Automatic_Provides_for_Python_RPM_Packages
Not only that, but the macro is just a convenience. It works for basic module names and thus is useful for the vast majority of packages. It doesn't need to handle every single case, because you can always just list the provides you want directly. That said, if you have a suggested patch that's useful for more than one specific case seen in one package, I'd be more than happy to have a look. Or if you can simply provide data on what provides you would want to see generated from a number of different cases, I can see if they'd be handled. But it's just not worth it to fix one or two packages.
(In reply to Jason Tibbitts from comment #5) > Not only that, but the macro is just a convenience. It works for basic > module names and thus is useful for the vast majority of packages. It > doesn't need to handle every single case, because you can always just list > the provides you want directly. > > That said, if you have a suggested patch that's useful for more than one > specific case seen in one package, I'd be more than happy to have a look. > Or if you can simply provide data on what provides you would want to see > generated from a number of different cases, I can see if they'd be handled. > But it's just not worth it to fix one or two packages. I think I have 3-5 such packages. * python-pillow (should handle cases for pythonX-imaging, pythonX-PIL, pythonX-pillow. all of those are well-known names) * python-scikit-learn (should handle pythonX-sklearn, pythonX-scikit-learn. all of those are well-known names) * python-requests-toolbelt (upstream well-known name is requests_toolbelt so I want it to handle pythonX-requests_toolbelt and pythonX-requests-toolbelt) didn't remember others, but I'm pretty sure I have at least one package which has 3 different well-known names. actually when I was thinking about naming I thought that %python_provide should automatically add Provides/Obsoletes for python2/python3 automatically based on argument, not by name of package. So for me this is still some bug which I would like to get fixed. Based on examples above I don't want to put manually Provides/Obsoletes for each package because it means that %python_provide is useless. Jason, I'm ready to help with that, just let me know how! ;)
Well, first learn a bit of Lua. Then look at /usr/lib/rpm/macros.python. It should be at least sort of obvious from there. Of course, I don't know what output you would want to see from what input, so I just can't say what you would do next. I also need to remove the annoying backspaces from that function; they're actually unnecessary except for blank lines.
Oh, and I should add: It's completely OK if %python_provides is useless for some particular case. I can't say any louder that it is just a convenience. Listing the Provides and Obsoletes manually is... exactly what you should do in a case that the macro doesn't handle. And that's perfectly fine. Covering very minor cases has a cost in maintainability which simply must be considered. So if it's easy, then great. But if it requires vastly complicating the existing macro, which is already somewhat magical, then... probably not, as there are only a few of us who understand RPM macro stuff down at this level. Though a separate macro would almost certainly be OK regardless. And I'm willing to look into it either way.
(In reply to Jason Tibbitts from comment #8) > Oh, and I should add: It's completely OK if %python_provides is useless for > some particular case. I can't say any louder that it is just a convenience. > Listing the Provides and Obsoletes manually is... exactly what you should do > in a case that the macro doesn't handle. And that's perfectly fine. but it should be absolutely same as produced by %python_provide, what's the point? > > Covering very minor cases has a cost in maintainability which simply must be > considered. So if it's easy, then great. But if it requires vastly > complicating the existing macro, which is already somewhat magical, then... > probably not, as there are only a few of us who understand RPM macro stuff > down at this level. > > Though a separate macro would almost certainly be OK regardless. And I'm > willing to look into it either way. I will check code of %python_provide and will try to write patch.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
Ok, I will fix it and attach patch here.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
Igor, is this still relevant? If so, would you ba bale to look into it?
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.