Re: [RFC] Build tag in RPM: from NVR to NVRB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux