Bug 1573326 - RFE: EPEL 7 needs a macro set update to understand: python2dist(" .. canonical .. ") Req, BuildReqs
Summary: RFE: EPEL 7 needs a macro set update to understand: python2dist(" .. canonica...
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: python-rpm-macros
Version: epel7
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
URL: https://fedoraproject.org/wiki/Packag...
Depends On:
TreeView+ depends on / blocked
Reported: 2018-04-30 20:41 UTC by R P Herrold
Modified: 2019-06-18 21:42 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-06-18 21:42:54 UTC
Type: Bug

Attachments (Terms of Use)

Description R P Herrold 2018-04-30 20:41:51 UTC
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:  python2-devel
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
BuildRequires:  python2dist(future)

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

Comment 1 Petr Viktorin 2018-04-30 20:59:38 UTC
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?

Comment 2 Jason Tibbitts 2018-04-30 21:13:23 UTC
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

Comment 3 Jason Tibbitts 2018-04-30 21:30:45 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.