Le mardi 30 juin 2020 à 21:33 +0200, Igor Raits a écrit : > On Tue, 2020-06-30 at 15:19 -0400, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/rpm_level_auto_release_and_changelog_bumping > > > > The change will make those packages auto-bump and auto-changelog at > > the rpm level, in an infrastructure-independent way. > > So how exactly is this supposed to work? From where will it get old > changelog, how packagers will migrate to this, how does it affect > reproducibility? The changelog is just one file in SRPM sources, and bumping is done from last build state which is just one key = value file in sources (storing the evr components, the last built time, and last build packager id). In reproducible mode last evr and packager id and build time are applied without bumping. You need to set %reproducible_build = true (or anything except false) in your ~/.rpmmacros (or config_opts['macros'], or as rpmbuild --define flags). The auto framework (and %new_package) split Release in separate %{source_release} %{dist} and %{post_release} components, which makes the implementation way easier than multiplexing things in a single Release tag and trying to untangle the mess later. A production implementation would probably split %{dist} in %{distcore} and %{distprefix} (the .gitdatehash things we stuff in Releases and in rpm changelogs as opposed to the fcX part we want to appear in Release but not in changelogs). I know where the offending code is in fedora- release and the split up is trivial to implement, but there’s no point in worrying about this level of detail before the core of the feature is approved (or not). The implementation is really simple and easy, it took me two days to write and test it because it reuses all the building blocks I had already done for my other change (without those jungling all the bits involved at various points of the spec file would have been challenging to say the least). > > So are you asking mock and koji people to implement something? Did > you > talk to them before submitting this proposal? > > > * Mock issue: > > https://github.com/rpm-software-management/mock/issues/599 I filled the mock issue to inform them. Again, this is a feature that took me two days to code (it did not exist, even in thought, last saturday). I was actually surprised at how easy it was to implement, given the months if was discussed on this list. At the mock level, there are two issues. The main one (and only critical one) is that bumping MUST occur when %build is executed, because a spectool or rpmbuild -bs is not a build event, only a full build is. That means the SRPM produced by rpmbuild -bs is not the bumped SRPM, only the SRPM produced by rpmbuild -ba is bumped. My (imperfect) understanding of the mock issue is that mock serves the first, not the second one at the end of the build process. The second issue is that bumping changelog requires filling a builder name and mail in the changelog line, and mock provides not easy way to pass those to the build process. If those two problems are lifted I see no special problem copr side (except using the new mock plumbing to pass builder iname & mail to mock). For koji/fedpkg things are a bit more challenging because you will want to back-commit the bumping to git once a build succeeds. Which is the main point clime and me disagreed earlier on this year. Though, it is not a show-stopper initially, a packager can back-commit manually if he wants the bump recorded till tooling catches up. While that adds constrains on the koji/git interface, that gives you a bumping mecanism totally generic and independant of the build infra, that does not rely on external python/ruby/whatever scripts to bum, and does not require messing with someone else’s spec just to trace and bump a rebuild. Just importing an srpm from one system to another will preserve the bumping state without any data loss. > > > > == Contingency Plan == > > > > There is no contingency plan because the change will happen or not > > at all. > > This is not true. If it will happen but then something will be > entirely broken we need to revert it. Thank you for your vote of confidence. I hope you realise that by that yardstick, nothing would be accepted, including your own changes, because something may always happen someday causing someone to revisit something. And, the last time a problem occurred, it was traced to an undocumented and unannounced rpm change that no one knew how to fix rpm-side, and that you spent more energy proving it need not be fixed than on constructive solution-finding. I freely admit that my code sucks and is way worse than the perfect code no one has written yet nor intends to write any day soon. -- 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
