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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
