Add option to not store expanded spec

[bmwiedemann]

Add option to not store expanded spec in .src.rpm
because some usages of macros are hard to make reproducible.

Fixes #2343

This patch was done while working on reproducible builds for openSUSE.

btw: if you have better proposals for the name of the value, I'll take it.

[pmatilai]

Sorry but NAK, adding an option to disable it invalidates the feature, because the whole point of the parsed spec is to always be able to see exactly how it was built.

[bmwiedemann]

Then we will have to carry the patch downstream.
Just one more on the long list

[bmwiedemann]

Besides that, the expanded .spec does not contain all the details e.g. which compiler+libs were used - all that goes into an SBOM outside of the produced package.

[pmatilai]

It's a bit sad if a feature aimed to help reproducability gets disabled by people working on the same goal. I'd be willing to discuss and attempt to address individual pain points, but I'm not going to agree to just swiping it under the carpet.

And sure it doesn't catch all the details, it's not (and doesn't claim to be) any end solution to all, it's just a single part in the big picture. Just like compiler versions and such are. Speaking of SBOM, there's also #2389.

I also fail to see much point in looking at a patch list of an enterprise distro, 4.14 is pretty long in the tooth from upstream POV.

[pmatilai]

The feature of storing the parsed spec may not seem that useful if all you have is mostly "classic", static spec files. But as the general trend is towards specs where a significant portion of the content is dynamically generated (whether via complex macros, dynamic spec generation from build itself etc), it's increasingly important to capture the actual content used for the build someplace just to be able to answer "what the heck happened". The src.rpm header was chosen for the reasons in the PR (#2047) but I'd be much more willing to discuss an option to store it in a different way than just "disable it".

[bmwiedemann]

We do have our share of dynamic magic - e.g. the python lua scripts to generate module packages for 39, 310, 311 and 312 from a single .spec. However these inputs all remain available in OBS, so are not a problem to reproducibility.

Could the expanded .spec become a separate artifact? e.g. we have generated rpmlint logs and build statistics as extra files, so another one there should be fine.