On Wed, Jun 22, 2022 at 11:09:13AM -0000, Michael J Gruber wrote: > > > > I also think that every package change (including rebuild) must be > > tracked in changelog. > > I think that convolution is at the very heart of the problem: > > As it is, dist-git tracks "packaging sources", i.e. spec and source hashes or files, and this determines the content of the src.rpm and its version. > > What you get when you build a binary rpm from that src.spm depends very much on the environment. And that environment is not reflected in the version nor in the built rpm (besides Build Host and Date). Well, it's reflected in the requires/provides/contents of the rpm too though right? If I build foo-1.0-1 against libbar-2.0-1 and then again against libbar-4.0-1 its going to require different libs at install/run time. > We sometimes still are in the old "dist-cvs mindset" where cvs really was not used as a vcs at all, but as as a way to drive the build infrastructure. But that mindset will not serve as any longer. We see that problem with every mass rebuild, such as now with pyth 3.11: Basically, one has to grep the changelog, i.e. unstructured textual information, to find out which pakcage has been rebuilt. If you built your package in rawhide after py3.11 was merged but didn't have that changelog entry it got rebuilt again, with an extra changelog entry. (If you pushed a fake changelog entry before the merge then...). Merge rawhide into f36 to get clean dist-git branches and you have a wrong/misleading changelog entry. (No, there is no py3.11 nor rebuild on f36.) Well, this proposal would try and inject some 'build changelog', but I'm not sure that really tells the entire story either. ;( > In addition, you don't know which defines were in effect during a build. (rpkg kind of solves that by having unparsed and parsed spec, at least for the rpkg macros.) > > I really think we need to stop abusing spec/changelog for things which are purely buildroot related. Let dist-git track whatever is needed to adjust the *package(ing)* to newer buildroots. Let the binary rpm track what buildroot it has been built against (be it a builtroot identifier/hash, macro settings used etc), or track it in koji/bodhi where the binary rpm has been built resp. the update has been pushed. I'm not convinced. This adds a lot to complexity... there's yet another place to look for changes, a number to look at to see if your version is the latest one. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
