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

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


is a small addition over the big %auto_macros change.


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).


Nicolas Mailhot
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to