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. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
