I'm confused; didn't Panu have issues with this?

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/139#comment-82285
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/141#comment-83325

I don't see any discussion where his concerns were addressed, but maybe that happened elsewhere.

I'm confused; didn't Panu have issues with this?

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/139#comment-82285
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/141#comment-83325

I don't see any discussion where his concerns were addressed, but maybe that happened elsewhere.

It happened in https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/141 - apologies, I didn't update the original PR

I had actually linked https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/141 and there isn't any discussion addressing Panu's concerns there.

AARGH, NAK!

This is completely against how %make_build and friends are supposed to work.
Revert this hack, NOW!

And then:

FWIW, when you get critical feedback from somebody, it's generally a good idea to wait for that somebody's comments before charging ahead with a new completely different version.

Were those actually addressed anywhere or is everyone just ignoring his objections?

I personally don't think this should have been merged to redhat-rpm-config without more discussion . Fortunately now there are more people looking at that package and so something like this will hopefully not happen in the future. I don't really know what to do now, although honestly removing it is still an option. It wouldn't be impossible to find any package using it.

Personally I have no real opinion because I haven't taken the time to look deeply into this. My concern is that strident objections from the leading expert on this kind of thing do not seem to have been addressed. And we should not be telling people to use the new macros until all of that is sorted.

@pmatilai just in case.

No, my concerns over the new version were never addressed or even acknowledged, and the whole works pushed to stable releases despite negative karma. I considered reverting it myself, but that didn't seem appropriate either as it's not "dangerous", just a bad design.

Thanks for the reply. This situation is quite troubling to me. For the record, I think this is the update you mention with the negative karma: https://bodhi.fedoraproject.org/updates/FEDORA-2021-7c42e41506

It was superseded by https://bodhi.fedoraproject.org/updates/FEDORA-2021-9042da4d79, which somehow doesn't seem to have negative karma on it, even though there's a red thumbs down icon. I guess that isn't enough.

Also related is https://bugzilla.redhat.com/show_bug.cgi?id=1988902 which has multiple negative comments which seem to have been completely ignored.

Problem is that now I don't know what we should do. There's a FESCo-approved feature behind this, but of course FESCo couldn't know up front that the implementation would have issues, since they just approved the concept. I don't think we should be endorsing these macros by recommending their use anywhere, and we can still remove this stuff if needed; at worst early adopters need to be fixed up. It's a sad situation but not an unworkable one.

Still, I haven't personally looked at this so I don't have any first-hand knowledge of what's actually wrong. Is there any way we could get a quick summary and perhaps some idea of what a more acceptable implementation might look like? I gather that there is general agreement that it's a good idea to allow the packager to supply some kind of hint so that things like parallel make can be scaled back.

Yeah, the goal is totally fine, although I would've hoped something upstreamable, and that'd need a more holistic view of the situation than just make flags.

For a Fedora-specific implementation I think I outlined an acceptable implementation on my posts on this topic, but this was scattered around on some many venues it's no wonder everybody lost track. The initial implementation had different issues, the issue in the new one is that it introduces parallel-build options to %make_build when the main purpose of that macro was to hide them from the packager. So bottom line, this should be something called at the top of the spec, which causes %_smp_build_ncpus (or %_smp_mflags for more limited scope) to be calculated differently. Not something buried in %build.

Please merge in https://pagure.io/packaging-committee/pull-request/1130 instead, which is a better implementation, thanks. Closing this.