Fabio Valentini wrote:
Speaking for myself: Using rpmautospec has massively reduced the
maintenance burden for the Rust stack, and also for other packages
that I maintain.
Due to the way optional dependencies / features are mapped to RPM
subpackages (this works like with "extra" dependencies in Python
packages, so this is not unique to Rust), you really should regenerate
the entire spec file with rust2rpm for every new version (and every
time when touching a patch that modifies features / optional
dependencies in Rust crate metadata).
Previously, this meant arduously copying the old changelog contents
somewhere, regenerating the spec file with rust2rpm, copying the old
changelog back, set the Release count to "0", run "rpmdev-bumpspec"
for the latest change, and commit the changes (usually with a useless
duplicate of the changelog entry as commit message).
With rpmautospec, all steps except "regenerate the spec file with
rust2rpm" and "git commit -c 'changelog contents'" are
eliminated,
which makes updating packages *much* easier, faster, and less
error-prone.
So it looks like in this case, it helps. That does not mean it needs to be
the default for packages which are not autogenerated though.
Additionally, not having Release counter and changelog in the .spec
file means that you can usually freely cherry-pick or merge bug-fix
commits across different dist-git branches. This wasn't possible
without rpmautospec due to merge conflicts caused by different Release
counter or changelog contents.
If I have a package that I upgrade in stable releases, I keep Release in
sync, and the changelog only really reflects Rawhide. I just fast-forward
Rawhide to the release branch, and the Release tag and the changelog go
along with it. If that includes some "Rebuild for Fnn mass rebuild" entries
that do not really apply to the release branch, so be it. At least it
explains why the Release number is as high as it is.
Kevin Kofler