Le 2020-07-05 23:55, Dan Čermák a écrit :
Hi Dan
So essentially you store the changelog in a separate file
The changelog is already detached in the F33 change
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
This F34 change adds bumping to the detached file
https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping
and use that to calculate the next release field?
The changelog file is not used as source of data, except as a reference
state that will be added to. Using the changelog file as source of data
would require quite a lot of complex and unreliable changelog format
parsing, so the bumping data is taken from another key = value file
(that uses the same persistence mechanisms).
Also the packager may decide to trim quite a lot of intermediary
changelog events, so the EVR and date in the last changelog entry are
not necessarily the EVR and date of the last build.
Given the other replies to this thread (that this is all local only,
unless koji does git commits), does that mean that it's still: dist-git
commit = rebuild.
To be part of official Fedora history the result of a build needs to be
committed yes. The change does not force you to build every commit, nor
to commit every build out there.
The "only" difference to the current state of affairs
being, that I don't have to specify the Release field myself?
Once you've modified a spec, and set a starting evr point in this spec,
further rebuilds do not involve touching the spec. Spec changes are real
spec changes, not spec changes to bump a release or bump a changelog.
The packager does not have to request the modification in his spec,
it’s done as part of the various %auto_foo calls the change introduced
Could you provide an example how this would look in practice?
If you want a demonstration of the auto framework and of changelog
detaching, you can take any of the non macro builds in
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-changelog-fonts/builds/
If you want to see a demonstration of autobumping, you need to rpmbuild
-ba manually right now, because of the two small limitations mock side.
So you need to take the redhat-rpm-config and fonts macro packages in:
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-bump-changelog-fonts/builds/
and rebuild one of the other packages in there.
The only difference between the two coprs is the redhat-rpm-config
package, there is no change in the fonts macro package or in the
automated packages themselves. Autobumping can be implemented without
any spec file change once the auto framework is used.
(The mock limitations are first, the fact that mock currently collects
the SRPM at the start, not end of the build process, and second, the
fact you need to pass packager ID that will end up in the changelog bump
to the build process and there is no way in the copr/copr UI do do
that.)
What I am currently missing from this proposal though is:
- How is this actually even implemented?
- How will this look in practice?
See above ↑
- Given that additional files would be put into dist-git, how do we
roll
this back in case things go wrong? (Having thousands of "remove
%autorelease" commits by releng could be an option here, albeit not a
pretty one).
Since bumping is a feature over the auto framework, and does not require
any additional spec change, it is enabled by registering bumping
processing in this framework, and disabled by removing this
registration. There is no need to change spec files or history. In fact
I use the same spec files to QA the auto framework and bumping, and
depending if the redhat-rpm-config version I test includes the bumping
or not, they will bump or not.
When bumping code is not present the additional key=value file bumping
uses is not auto-added to sources, so the next srpm import will clear it
from sources the same way patches disappear from sources once no longer
used (and can linger forever if a packager does not import srpms and
does not git rm those files explicitly).
Removing the auto framework is something else altogether. Because its
aim is to massively simplify spec files (in opt-in, not mandatory mode),
you can not go back without undoing the spec simplifications.
However, because great care was taken to define a clean and generic spec
syntax when using the auto framework, you could replace it will multiple
reimplementations without changing spec files. The %auto framework spec
API is basically
%prep
%auto_prep ← automated processing
It’s hard to go more generic than that. (You might want to remove the
%auto calls altogether and have %prep, for example, call %prep by
default, but that would remove the packager choice to use or not the
%auto calls, and to insert custom processing before those calls).
The only "irregularity" is that the %auto macro in %sourcelist is named
%auto_sources (likewise for patches), but that could be changed if
people wanted it changed, and is an artefact of the general mess sources
and patches are in rpm, with layers over layers of confusing things
named almost the same, but not exactly the same.
Regards,
--
Nicolas Mailhot
_______________________________________________
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
