-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Thu, 2020-07-02 at 11:17 +0200, Nicolas Mailhot wrote:
Le 2020-07-02 09:52, Florian Weimer a écrit :
- Nicolas Mailhot via devel:
How do I let rpm generate the changelog automatically?
This feature is not changelog generation, just changelog bumping on build events. You still need some other method to put non-build events in the changelog.
What is “changelog bumping”? Why is it needed? What about release bumping?
Changelog bumping is the act of putting the actual release bump and build time in the changelog.
With the change, the spec is able to self-compute its next release if the spec file evr is older or equal to the last build event.
How does it know that "last build event"?
On build, it will both bump the release, without touching the spec file (that is release bumping) and commit the new build event timestamp in the detached changelog file at %build time (that is changelog bumping).
The detached changelog is just one more file in SRPM sources, which is modified by rpmbuild at `%build` time with other files rpmbuild modifies. The tricky part is to modify the source file as a source file so rpmbuild adds the result to the produced SRPM (and, that does not work in mock right now, because mock serves the SRPM that existed at the start, not at the end of the build. Though it’s probably just a matter of getting mock to call again its SRPM creation method at the end of the build).
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
Can you list the relevant %auto macros explicitly somewhere? Is %autosetup included in the set of macros that trigger this behavior?
%autosetup is not part of the new framework, all the new %auto entry points have %auto_something name/
Auto release bumping and auto changelog bumping involve registering some processing in the preamble (to compute the next evr), in %sourcelist (to deal with the source files involved in saving state) in %build (to commit the new data to disk once the build is ongoing) and in %changelog (to get rpmbuild to record the new changelog state in package metadata)
ie it registers processing in %auto_pkg, %auto_sources, %auto_build and %auto_changelog
The bumping is done by the buildsys subsystem ie practically by %new_package (called by %auto_pkg, directly or via %buildsys_pkg), by %buildsys_sources (called by %auto_sources), %buildsys_build (called by %auto_build) and %buildsys_changelog (called by %auto_changelog).
It’s done by the buildsys subsystem because the %buildsys subsystem is tasked with writing the SRPM header in the new %auto_call framework, so only it knows which of the various (sub)package epochs and versions are the ones that apply to the SRPM.
This may seem a bit complex and convoluted, but that’s because autobumping
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros...
is a small addition over the big %auto_macros change.
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros...
And it is small because the big change provides all the low-level infra to code such high level features easily.
The big change was not done for autobumping. It’s only once I coded it for other packaging needs that I realized it made implementing autobumping trivial (trivial to me after all the other changes, maybe not so trivial for the average macro reviewer).
Regards,
-- Nicolas Mailhot _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@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/packaging@lists.fedoraproject....
- -- Igor Raits ignatenkobrain@fedoraproject.org