On Thu, 30 Apr 2020 at 20:40, Nicolas Mailhot via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Le lundi 09 mars 2020 à 00:26 +0100, clime a écrit : > > Hi, > > > the code would fail because at that point, the > > git metadata is already missing (they are not included in srpms). > > Can’t storage of built-time information in srpms be fixed instead of > adding a whole new overlay over existing tools, that ties building to > Fedora infra? > > There are lots of practical applications of being able to record build > time info in srpms (for example, I’ve been asked to record the > buildroot state one way or another, and, IIRC, samba called rpm in its > scripts for the same reason). It took me a while to realize you don't mean BUILDTIME header info but state of build environment that affects build of srpms :). Anyway, maybe? I think this might be more handy for rpms rather than for srpms. In most cases, srpms are only source carriers? If this should be the way for dynamic changelog/release, you would still first need something that translates relevant git metadata into something which rpm can work with. I don't think rpm should do it on its own as it would become tied to git or any other future scm. Can you elaborate on what samba did? I would like to know because it sounded interesting. --- I don't think this proposal ties it to Fedora-Infra. Anyone using either mock or rpkg-based tool should be able to use it according to this proposal. > > Modules went the overlay route, it was not their best decision. I don't think it is a proof that overlay-based solution are wrong though. By the way, modularity, in my opinion, would be great if it produced rpms (created by mixing/overlaying rpms from built modulemd) instead of yum sub-repos. That way we wouldn't need to duplicate things like Obsoletes or Requires on another layer and it would get a proper binary format for distribution. > > Regards > > -- > Nicolas Mailhot > _______________________________________________ > 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 _______________________________________________ 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
