Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit :
Nicolas Mailhot via devel wrote:
> So if you want to push Fedora release logic to its ultimate
> the thing that should be in charge of committing the new
> release/changelog build state to package history in git is bodhi,
Why do build events need to be recorded in the Git history in the
The changelog is built-in the rpm format. Therefore, it needs to exists
at rpmbuild stage. Therefore, you need to record past changelog state
so new builds are consistent with previous builds.
You may argue that the existence of scms like git makes built-in
changelogs irrelevant. People that have to debug problems in systems
that mix packages sources will disagree – they have no wish to comb
multiple external scms to find what was changed in a package set that
breaks (hard to do when the thing that broke is networking for
And, even if you removed completely the changelog from the rpm format,
you’d still need to manage package releases.
So why is NEVR required to change when nothing in the package source
The NEVR is required to change because you need to publish a new
package ID to clients, so clients know they have an update to deploy.
That has nothing to do with koji limitations, it’s a requirement or the
rpm update system, or pretty much any change management system for that
It seems that several problems would just disappear if a rebuild
would generate a unique package ID without a Git commit.
That’s exacly what the change does.
Here's an idea: We could mandate that Release must expand a
called buildtag. This macro would have a new value every time,
monotonically increasing. A timestamp seems easiest, but that should
bean implementation detail that could be changed without breaking
Because things are slightly more complex than you think they are, the
counter is not just a timestamp, and there are two not one counter, but
yes, again, that’s exacly what the change does.
(The build time is already stored in packages, and could
theoretically be used to tell builds apart, but that would require
changes to lots of tools I guess.)
The build time by itself is not sufficient because you have branches,
and scratch builds (which are basically abandonware branches) so
parallel package history exists and a single monotonic timeline can not
Nevertheless the last build time is useful (for changelog bumping, if
nothing else) and is one of the things the change stores as past state
(you could try to deduce it from other things, but why bother, a
timestamp variable is cheap and easy to manipulate).
Mass rebuilds would no longer make any Git commits. They would just
take the latest version and submit it for building.
Again, that’s basically what the change does. A build stores counters
and date as they existed as the time of the build in one of the SRPM
source files. The next build reads this file and computes a higher
release. No external bump script involved. No spec file change
required. The spec file can be left unchanged forever, the release info
in there is just the last release someone made a change to the spec
files, and everything autobumps from there.
All you need is to pass the "last build" info from one build to
another, which is done via importing the results of last build at the
start of the new build. Since the import relies on SRPM content and
nothing else you can even move the build chain from one buildsystem to
another it will still work.
While timestamping would remove the need to pass the last build info to
the next one it would also break all the workflows where several
rebuilds are done in parallel for separate needs, and the latest
rebuild is not necessarily the one you want to keep.