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
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
