-----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_mac...
is a small addition over the big %auto_macros change.
https://fedoraproject.org/wiki/Changes/Patches_in_Forge_macros_-_Auto_mac...
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(a)lists.fedoraproject.org
To unsubscribe send an email to
packaging-leave(a)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.fedoraproje...
- --
Igor Raits <ignatenkobrain(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl79pwsACgkQEV1auJxc
Hh5oixAAlyinJfmNKCVQcx/Kh11xb+MwW9UzGynhW1cTUAe1D8vslH0jtEJjJRRm
nXMtIyNoj0ny5Uo+ddABdQ3V86qqh/U46K5XK2FbGPq9a0hmI254KgJDLt4hqtaT
Dqw7+LK2jwbb63WBacsxJG6dGhvS9cOGxoxo+jMQ3uocLN1RrbTI/Du64i8d3Enk
Jmu3v0YKm3V+VyRtal2O+BGphzANS0D0rodHMH/8zmcT50Mt41QMFl+16PPDBcsn
qgyy/3tmruPmxUDCO5xFzJlA50qT5AMSWy8pOKqFdr+5hUaYW6rPkvXoC7uun08V
FnW/XGVHHv7iwz2CUCqoLwzb6wlyKzOyjxh3RGTIt+FXz1AfQ2tZWSbSvlElBce9
eRMb+v5yoURHMYK4Iazy9HMZa2mp7lcXFWE7qkTxwVwClkQ1YuaCEeSIVpblFuFw
l8w47QzcyGPwIi6GMqJyp5dpqLD15JetVIXQfF8/V5OCWMHNgqbbaef5Q9JNnc9K
PQ31VyhsAc+/PGkX5vNM31GIFvJSS3BmJ8IXNxO4V+eTdESJVOQGHqsq8/UI35AC
s5XDxb+AXUn5q2rREV7+EimE5CxV8ouRKMG+gJJ809KqwIr6jtML1zcQpO2ZkPNo
e8MEPw0G5izmY1Cp5qQ8/WfRf8cDtRfsuxXU9Zm53AEGVLY9mGg=
=DXfR
-----END PGP SIGNATURE-----