Hi,
Anyway, here is what I would personnaly consider a robust, inclusive,
and future-proof design:
— a %{use_dynstate} rpm variable enables dynamic changelog/release
behaviour
— probably initialy set to false distro-wide, to let volunteers test
the thing by setting it to true iin their specs,
— then to true (opt-out), when kinks have been fixed, and FPC/FESCO
greenlights general availability
– when activated, last changelog, evr and %{dynrel} state are saved in
one or several detached files
— evr computed using a fixed neutral %{dist} value (for example “-”
since it’s forbidden in %{dist})
– those files are given standard rpm variable names and added to
Sources:
– manual packager Source900: %{dynstate} or whatever
– rpm later updated to allow source file declarations via macros at
to eliminate boilerplate (I need this in forge and go packages)
– or the detached files are set in stone as separate Tags with a
default value overridable via the %{dynstate} variable in a new rpm
version
– the packager adds %{dynrel} wherever he sees fit in his Release
string
– at fedpkg commit time changelog state is updated with info taken from
fedora git state, *without* evr and build date
– that’s Fedora-specific integration, exact commit/tag syntax to mark
things to inject or ignore TBD Fedora-side
– fedpkg commit sets a tag in git to mark anything older can now be
ignored for changelog generation purposes
– detached changelog state remains packager-editable, like the in-
spec changelog today. That allows pruning useless no longer relevant
stuff and fixing grammar errors
— at rpmbuild -bs stage
– evr is computed using the same neutral %{dist} value as before, and
the saved %{dynrel} value
– if it is equal to the previously saved evr %{dynrel} is bumped and
saved in the detached file
– a build line is added to the detached changelog, using the current
date and full evr (without %{dist} neutralization)
— that probably requires defining a rpm variable to track whom the
build is attributed to
– it can default to "Anonymous coward" or whatever if not explicitely
set
– Koji, OBS and Copr can set it to whoever asked them to build the
package
– the result constitutes the new srpm (either first or second level
srpm as upstream rpm sees fit)
– that’s generic non Fedora-specific behaviour that work as well in
rpmbuild -bs, mock, copr, koji, OBS, whatever, with or without Fedora
git presence
– Koji/copr need to commit the new dynamic dynrel/changelog state to
git (a build-striggered state change is commited by the build system)
And yes that requires some work rpm-side. That is necessary to maintain
the rpm decentralized design and keep srpms independent from anyone’s
git state. Personnaly, I don’t see the point of pretending we can move
our infra forward without ever touching rpm. The cardinal sin of
Modularity was attempting to create an overlay over existing rpm/dnf
behaviour, without changing this behaviour when it needed improving.
Contrat that with dynamic buildrequires or weak deps that slotted into
our workflows with hardly any ripple. Though they were major feature
changes. But, they were done with rpm upstream, instead of trying to
bypass it.
Regards,
--
Nicolas Mailhot
_______________________________________________
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
