On Sat, Dec 31, 2022 at 9:38 PM Stephen Smoogen <ssmoogen@xxxxxxxxxx> 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@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
