Description of problem:
I see the new form of BR's in spec files sych as the one for buildtot
so: of the form:
BuildRequires: python2dist(setuptools) >= 8.0
# For Python 3, it requires python3dist(twisted) >= 17.9.0
# c.f.: https://github.com/buildbot/buildbot/blob/v1.0.0/master/setup.py#L458-L461
BuildRequires: python2dist(twisted) >= 16.1.0
BuildRequires: python2dist(jinja2) >= 2.1
BuildRequires: python2dist(zope.interface) >= 4.1.1
Version-Release number of selected component (if applicable):
This rolled in seemingly from the URL page noted above at:
> Starting with Fedora 26, these Provides tags can be used to list Requires and BuildRequires ...
That URL also notes:
The following macros are defined for you in all supported Fedora and EPEL releases:
but I think it does not address a needed transition case. Also it seems to be one addressible by macro additions, and that via macro, we are able to address the conversion load for EPEL 6 and more importantly EPEL 7, so that 'rpm-build' can understand and expand the new forms, back to the prior known cases
The alternative is to manually seek an addition of new R/BRs, which as a practical matter will never get timely accepted upstream in (immutable and non-conflictable by EPEL) packagings
I'm not sure I fully understand the report here.
- If all distros you are targetting with this specfile provide "python2dist(twisted)", you can use that.
- If some don't, you need to use the Fedora package name, "python2-twisted".
The "new" convention is there to better support automating creation of RPMs from upstream packages (e.g. wheels), which don't map well to Fedora package names.
But if you need to share a single specfile with older systems, you don't need to use it.
If that doesn't address your concern, could you please clarify?
There's nothing useful a macro could do here anyway, so I don't understand the request. It's also not particularly specific, either; if you think something could be solved by a macro, you should at least give some idea of what you think the magic macro would look like and how it would be used.
EPEL python packages could certainly carry the new Provides:; that would require backporting the dependency generator and I'm not sure if that's been done or if this would be the package in which to do it.
RHEL-provided python packages will simply not ever have the necessary Provides, no matter what we do in Fedora My stub packages do indeed have the python2dist() provides included (except maybe for the first couple that I did) so that would be a way forward. But you'd have to request those from me individually. See https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages
On a second look, I think that it may be tricky to backport the python dependency generator to EPEL. We would have to somehow override the stock rpm-build provides /usr/lib/rpm/fileattrs/python.attr, which I don't think is possible without conflicting.
It might be possible to just force a definition of %__python_provides but I am not sure that would work, and overriding the definition of %_fileattrsdir (and copying most of the contents) just to get this effect seems to be beyond what is reasonable.
I think the bottom line is that you will have to accept that there are some things which you just cannot have in EPEL. Maybe the EPEL that follows the next big RHEL release will be better, but it too will fall behind in time.