Miro Hrončok wrote:
> It goes like this:
>
> - master and f31 are at the same commit "aaaaaa"
> - I push a change only possible in rawhide, commit "bbbbbb" to master
> (it includes release bump and changelog entry)
> - a commit relevant for both, "cccccc" is pushed to master
> (it includes release bump and changelog entry)
> - on f31, I run `git cherry-pick cccccc` => conflict
>
> I don't worry about having "Fedora 31 mass rebuild" or "Rebuilt for python
> 3.8" changelong entries in Fedora 29 (it gives me a little flinch, but
> nothing serious). i worry about the bbbbbb commit I cannot merge into f31
> (e.g. if it implements some Fedora 32 change).
>
> Then obviously, people start inventing %if spaghetti.
And %if is actually the correct fix for this issue.
See, e.g., the one I had to add to qt5-qtwebengine after you broke it for
F29 with your mass change:
https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/05a52d121d49972989aea8127e22e25f0292333c?branch=master
IMHO, mass changes are only acceptable if the result builds on all supported
Fedora releases. Breaking the build for F29 is only acceptable after it
reaches EOL. So your mass change should have included this %if, or ideally
an update pushed to F29 to make the conditional unnecessary.
That's your opinion. Some packagers (like me) actually maintain the branches for each fedora release separately.
Doing mass changes that way would also place a pretty big burden upon anyone who actually wants to work on fedora-wide improvements.
Additionally, if-guarding every non-backwards compatible change will result in unmaintainable, brittle and broken .spec files pretty fast. Nobody should be expected to work through if-else-endif spaghetti (and I'm not even talking about automated tools here, which almost never will handle conditionals entirely correctly, and probably never can). And never mind that people don't actually remove conditionals for EOL fedora releases ...
Fabio