On Sat, Dec 31, 2022 at 9:38 PM Stephen Smoogen <ssmoo...@redhat.com> wrote:
>
> My main questions are what is this supposed to fix long term?
>
> I have guessed that it has to do with automation, the shrinking number of 
> active packagers in operating systems, and the exploding number of packages 
> in requested languages (Rust, Go, jq, etc). However, that is just a guess and 
> it doesn't really say "HOW" this gets to dealing with this long term. It also 
> isn't clear what the underlying remaining active packagers want to be part of.

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.

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.

Fabio
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to