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 > > conclusion, > > the thing that should be in charge of committing the new > > release/changelog build state to package history in git is bodhi, > > not > > koji. > > Why do build events need to be recorded in the Git history in the > first place? 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 example). 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 > has changed? 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 matter. > 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 macro > 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 > things. 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 represent that. 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. Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
