Hi, I'm relunctantly coming to the conclusion that tracking VCS forge information (url, commit, tag, version…) in rpm variables is not sufficient. The reason is the interaction between: — BuildRequires generators https://github.com/rpm-software-management/rpm/issues/104 — multiple rpm source archives — the fact that those sources may not be synchronized (with different upstream versions, tag, commits, etc) Because rpm has no notion of BuildProvides, BuildRequires generation must be careful to remove the elements the build will produce from BuildRequires. That makes BuildRequires generation a full-build operation, unlike the nice per-element operation Requires and Provides generation is. Removing the elements the build will produce requires knowing the versionning characteristics of each one of them. And, when people do unsynchronized sources builds (as does happen, unfortunately, in the real world) one can not assume all the elemants share the same versioning info. So BuildRequires generation is not: for each atom, genbr --version=atomversion atomname nor genbr --version=atomversion atomname1 atomname2… but genbr --version=atomversion1 atomname1 -version=atomversion2 atomname2… And at that point most CLI arg parsers will break horribly, even if you've been careful to track all the required info in rpm variables, and can technically construct the whole command line. (massively simplified example here, upstream language-specific versionning is not a single version atom but a composition of multiple variables) So, my cunning plan®, whenever I get there, would be to modify forgesetup to write in each archive extract directory a forge.json file will all the versioning information of the VCS extract, and just let BuildRequires generators read this file an do whatever they want with it. That probably means making forgesetup auto-add a BuildRequires on a json writing lib, since I doubt the default build environment includes one. The forge.json thing could probably be useful for other things I can't imagine today. Any idea on how to make it all simpler? (except that people should not do multi-source unsynchronized builds, which I violently agree with, but in the real world they do those things so the tooling must adapt). Alternatively rpm could grow a BuildProvides notion, which would make the whole problem go away, but I sort of feel it's too early to ask for that and just getting https://github.com/rpm-software-management/rpm/issues/104 finished would be great Regards, -- Nicolas Mailhot _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
