I also think that every package change (including rebuild) must be
tracked in changelog.
I think that convolution is at the very heart of the problem:
As it is, dist-git tracks "packaging sources", i.e. spec and source hashes or
files, and this determines the content of the src.rpm and its version.
What you get when you build a binary rpm from that src.spm depends very much on the
environment. And that environment is not reflected in the version nor in the built rpm
(besides Build Host and Date).
We sometimes still are in the old "dist-cvs mindset" where cvs really was not
used as a vcs at all, but as as a way to drive the build infrastructure. But that mindset
will not serve as any longer. We see that problem with every mass rebuild, such as now
with pyth 3.11: Basically, one has to grep the changelog, i.e. unstructured textual
information, to find out which pakcage has been rebuilt. If you built your package in
rawhide after py3.11 was merged but didn't have that changelog entry it got rebuilt
again, with an extra changelog entry. (If you pushed a fake changelog entry before the
merge then...). Merge rawhide into f36 to get clean dist-git branches and you have a
wrong/misleading changelog entry. (No, there is no py3.11 nor rebuild on f36.)
In addition, you don't know which defines were in effect during a build. (rpkg kind of
solves that by having unparsed and parsed spec, at least for the rpkg macros.)
I really think we need to stop abusing spec/changelog for things which are purely
buildroot related. Let dist-git track whatever is needed to adjust the *package(ing)* to
newer buildroots. Let the binary rpm track what buildroot it has been built against (be it
a builtroot identifier/hash, macro settings used etc), or track it in koji/bodhi where the
binary rpm has been built resp. the update has been pushed.