On Thu, 3 Dec 2020, Michel Alexandre Salim wrote:
Apart from the usual package-not-available story (which I want to fix as part of my work bringing up the EPEL Packagers SIG), my current snag is that python-tox-current-env uses %generate_buildrequires which does not work on CentOS 8:
CentOS 8 is still on RPM 4.14: <mock-chroot> sh-4.4# rpm -q rpm rpm-4.14.2-37.el8.x86_64
I'll put up a patch to hardcode dependencies for non-Fedora releases, though that sorts of defeat the purpose of dynamic build requirements. Then again, this is only needed for EPEL8, since EPEL9 will have a new enough RPM.
Given that %generate_buildrequires is the selling point of pyproject- rpm-macros, I'm guessing a better way forward for EPEL8 would be to not require it on EPEL8 since there's no way it would work, since RH won't update RPM?
Is %generate_buildrequires suppose to work for packages which do not used python ?
From the name I would expect it to, but reading that doc makes me think %generate_buildrequires *is* python specific. If so, the name is misleading.
(I am also confused/suspicious of the point of a macro to automate build requires, except as a step on a path to somewhere else. If build requirements need to be stated explicitly, then automating their statement is a good way of hiding an issue that needs to be reviewed whenever changes are made. )
On 12/3/20 10:06 PM, Andrew C Aitchison wrote:
Is %generate_buildrequires suppose to work for packages which do not used python ?
Yes, see https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
From the name I would expect it to, but reading that doc makes me think %generate_buildrequires *is* python specific. If so, the name is misleading.
When you read the docs at https://src.fedoraproject.org/rpms/pyproject-rpm-macros that is indeed Python specific. It describes the following:
%generate_buildrequires %pyproject_buildrequires
But you can heve many other things, e.g.:
%generate_buildrequires echo fruit-cake
Or:
%generate_buildrequires %cargo_generate_buildrequires
(I am also confused/suspicious of the point of a macro to automate build requires, except as a step on a path to somewhere else. If build requirements need to be stated explicitly, then automating their statement is a good way of hiding an issue that needs to be reviewed whenever changes are made. )
Indeed, things are less explicit when reading the spec file. OTOH When upstream requirements change, one does not need to update them manually. No more obsolete buildrequires (they tend to happen, really).
On Fri, 4 Dec 2020, Miro Hrončok wrote:
On 12/3/20 10:06 PM, Andrew C Aitchison wrote:
Is %generate_buildrequires suppose to work for packages which do not used python ?
Yes, see https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
Thanks. Now that I read that, this looks like a good plean.
(I am also confused/suspicious of the point of a macro to automate build requires, except as a step on a path to somewhere else. If build requirements need to be stated explicitly, then automating their statement is a good way of hiding an issue that needs to be reviewed whenever changes are made. )
Indeed, things are less explicit when reading the spec file. OTOH When upstream requirements change, one does not need to update them manually.
Certainly a very good step in this direction. Is there anything to save an upstream devel from having to know that, say, what Ubuntu calls "libX11-dev", CentOS calls libX11-devel ?
No more obsolete buildrequires (they tend to happen, really).
Yes; I have seen that.
Thanks for the pointer to https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
On 12/3/20 14:06, Andrew C Aitchison wrote:
On Thu, 3 Dec 2020, Michel Alexandre Salim wrote:
Apart from the usual package-not-available story (which I want to fix as part of my work bringing up the EPEL Packagers SIG), my current snag is that python-tox-current-env uses %generate_buildrequires which does not work on CentOS 8:
CentOS 8 is still on RPM 4.14: <mock-chroot> sh-4.4# rpm -q rpm rpm-4.14.2-37.el8.x86_64
I'll put up a patch to hardcode dependencies for non-Fedora releases, though that sorts of defeat the purpose of dynamic build requirements. Then again, this is only needed for EPEL8, since EPEL9 will have a new enough RPM.
Given that %generate_buildrequires is the selling point of pyproject- rpm-macros, I'm guessing a better way forward for EPEL8 would be to not require it on EPEL8 since there's no way it would work, since RH won't update RPM?
I've been playing around with a hacked version of pyproject-rpm-macros which at least allows some basic functionality in EPEL8. Comments welcome.
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/284
epel-devel@lists.fedoraproject.org
-
Andrew C Aitchison -
Miro Hrončok -
Orion Poplawski