Re: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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_-_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

- -- 
Igor Raits <ignatenkobrain@xxxxxxxxxxxxxxxxx>
-----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-----
_______________________________________________
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




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux