Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <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
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux