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.
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_-_Detached_rpm_changelogs
is a small addition over the big %auto_macros change.
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_macros_-_Detached_rpm_changelogs
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
