Similar situation happens if you have spec file in upstream. The problem
is that mass rebuilds are
adding entries to dowstream spec file only, so you have to manually
merge the upstream and
downstream or ideally do a backport upstream before realese. This is
nice and easy solution for
the issue.
Even though, we solved that by using Packit for releasing.
Jirka
Dne 01. 01. 23 v 20:51 Fabio Valentini napsal(a):
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
_______________________________________________
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
