Le mercredi 01 juillet 2020 à 12:27 +0200, Dominik 'Rathann'
Mierzejewski a écrit :
That's not detailed at all. You should provide at least one
here (or a direct link to one somewhere else on the wiki).
Thank you for your attention and kind review. yes the wiki page was
completely insufficient, I did it at the last minute to honor
deadlines. Please check if it is ok for you now.
Anyway here are some answers I added to the wiki
What's "autobumping" here
The change will make packages that use the %auto_<call> redhat-rpm-
config macros auto-bump and auto-changelog at the rpm level, in an
infrastructure-independent way. The %auto_<call> framework is proposed
In that context, auto-bumping means that a SRPM, produced in any
compatible build system (that is, any build system that does not
inhibit low-level rpmbuild behaviour), will rebuild by default to a
release higher, than the last build release, in the next build system
it is imported into, without any manual change to the SRPM source
Auto-changelog means that the build event will also be traced in the
rpm changelog (again, without any manual change).
and how is it better than rpmdev-bumpsec?
Unlike rpmdev-bumpsec, the feature is automatic.
It does not require explicit human action. Releases get bumped even if
the human forgot a particular release has already been built.
It does not rely on an external tool, nor requires this external tool
to be able to parse a spec file (which can be difficult for heavily
automated spec files like the ones that take advantage of %auto<call>
A rebuild does not touch the spec file at all. That means, the spec
files changes tracked by your favorite scm, will show only spec logic
changes, without drowning those in no-logic-change build events.
> == How To Test ==
> A redhat-rpm-config packages with the changes and some example
> packages are available in
A diff with changes
The current code state is visible in
It’s one small commit on top of the huge change queued in:
That PR can still evolve based on feedback and testing. Therefore, I
can’t promise that the auto-bumping logic will always apply directly,
just that it will look more or less this way after rebasing. I do not
rebase it on every change to the other PR.
This is very young code, there are probably lots of easy things to tidy
up in there. However it works.
Why is a separate "rpm-changelog.txt" file with manually maintained
changelog better than current manually maintained changelog inside
This change does not separates the changelog. The separation is already
that this change builds upon
Without separation, we would lose the benefit of auto-bumping at the
SCM level, since no-logic-change rebuilds would still result in a spec
Separation makes automation a lot easier since adding to the changelog
is just pre-pending some lines, and does not require any knowledge of
rpm syntax. Auto-bumping will add a "* date name evr" line on the next
rebuild, so changelog additions can limit themselves to plain text
descriptions of new changes at the top of the existing file.
Separation is a requirement for auto-changelog bumping at the rpm
level. Once rpmbuilt is lauched, it can not modify the processed spec
file. Therefore making the changelog modifiable by the build process
requires splitting it out of the spec file first.
How about using git commit log for changelog instead?
This is a low level change that does not depend on any specific
infrastructure, git included. It works directly at the rpm level.
An infrastructure that uses git, can feed git commit events to the
detached changelog file, using dumb or elaborate git commit hooks, and
any other method it wants to implement. The auto-bump logic does not
care, it will use the detached changelog file in the state it exists at
the start of the build process.
Because the logic catches all rebuilds, regular manual trimming of the
lines that add no value is recommended.
> To get beautiful changelogs, you also need to add
> %buildsys_name Your name
> %buildsys_email Your email
> in ~/.rpmmacros
What about having one macro called %buildsys_packager instead of two?
You're always using them together, anyway. It'd be similar to the
existing %packager macro, too.
This is certainly doable and will simplify the code. Therefore, I will
do it. I was formatted by the way name and email are separated in
Please ask any other technical question you may have, they are helping
me to make this Fedora feature better