%generate_buildrequires

[Andrew C Aitchison]

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?
>
> https://src.fedoraproject.org/rpms/pyproject-rpm-macros

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.
)

[Miro Hrončok]

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).

[Andrew C Aitchison]

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

[Orion Poplawski]

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?
> >
> > https://src.fedoraproject.org/rpms/pyproject-rpm-macros

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