RPM 4.18.1 released!

[Michal Domonkos]

Hi Miro,

Apologies for the late reply, I somehow managed to completely miss your email.

On Tue, Mar 14, 2023 at 12:54:05PM +0100, Miro Hrončok wrote:
> > Restore BuildRequires check in rpmbuild -bp (regression in 4.15.0)
> 
> Does this mean I cannot run rpmbuild -bp (and hence e.g. fedpkg prep in
> Fedora) without installing all the build dependencies? Or did I understand
> that wrongly?

Yes, that's correct.  It's a bugfix of a regression in 4.15 where it was
accidentally broken in a refactoring.  More details here:
https://github.com/rpm-software-management/rpm/pull/2271

If -bp is desired on a system without the build deps installed, and the package
doesn't require any of those for %prep, then one can simply issue the --nodeps
flag to rpmbuild.

In fact, fedpkg prep does exactly that, it uses --nodeps (you can check that by
running fedpkg --verbose prep).  So in practice, fedpkg isn't even affected by
this change and can still fail if a package requires a build dependency in
%prep.

> > Issue a deprecation warning on %patchN syntax
> 
> Is there a timeframe for actual removal? There are ~10k such lines in ~3.3k
> Fedora Rawhide packages.

I'm not aware of any specific plans here but it has to be a major release where
this happens, and 4.19 (this year's Q3) would perhaps be too early, which means
4.20 (next year's Q3) at the earliest.

> > Don’t embed CPU count of build system in packages (#2343)
> 
> I worry that the way this was fixed is probably a breaking change. Packages
> out there use e.g. SPHINXOPTS='%{?_smp_mflags}' (~50 Fedora packages) which
> will turn into SPHINXOPTS='-j${RPM_BUILD_NCPUS}' which will not work.

Oh, this may indeed be an issue.  There seems to have been an assumption that
the %_smp_mflags macro never includes any shell variables that need to be
expanded at build time.  This assumption has now changed with 4.18.1.

In any case, there doesn't seem to be a reason for the macro to be
single-quoted in SPHINXOPTS.  In that sense, it's a packaging issue that needs
to be addressed in the affected packages.  That said, we might as well take
into consideration the fact that this is a *stable* update of RPM.  Panu, any
thoughts on this?

-- 
Michal Domonkos / RPM dev team / Red Hat, Inc.