On Sat, 29 Feb 2020 at 10:15, Nicolas Mailhot via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Hi,
>
> Anyway, here is what I would personnaly consider a robust, inclusive,
> and future-proof design:
I will need to ask some questions to really understand it.
>
> — 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
You mean the last changelog, evr, and %{dynrel} are stored once
%{use_dynstate} is set and and after one invokes fedpkg commit?
I think there should be some explicit action (e.g. the commit) to generate
the files after I set the %{use_dynstate} value to true in the spec file.
How is %{dynrel} computed here at this stage - does it have something
to do with the number of commits from the latest version change or
similar?
> — 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
Is the intention here that with each new build of the same package,
the value of %{dynrel} is bumped and committed back?
Only if other parts of release (other from %{dist} and %{dynrel}) or version or
release have changed, nothing is done? That means the evr file read from the
repository needs to contain somehow outdated values at this point (when srpm
is being built in build system), otherwise %{dynrel} would be always bumped?
> – 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
I think today's changelogs do not contain name of the person who
built the pacakge (unless it is a mass rebuild), do you think something
like this is needed? Usually a person responsible for release of the
package (for the given "evr") is mentioned in the changelog record.
> – 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)
You mean there would be different kinds of built srpms? Or otherwise
i don't under why upstream rpm (i understand it as
https://github.com/rpm-software-management/rpm)
should be involved here. What is meant by the "levels"?
> – 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)
For copr, it is not possible, because it has read-only access to git
repositories being built.
> 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.
I think there are good examples where some things can be done without
rpm changes - e.g. the simple-koji-ci to do automatic scratch builds
on a new commit.
> 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
_______________________________________________
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
