Le vendredi 03 juillet 2020 à 11:03 +0200, Pavel Raiskup a écrit : > On Friday, July 3, 2020 9:51:20 AM CEST Nicolas Mailhot via devel > wrote: > > it will certainly be possible to compute a second level of sources > > during the dynamic buildrequires first pass over prep, and the > > change > > makes the forge macro code modular enough the second level will be > > auto-registered in sourcelist, but how is the buildsystem supposed > > to > > provide sources that did not exist during its first pass over the > > spec > > file? > > Possible. But I personally think that "dynamic buidlrequires" should > stay > working with BuildRequires, not Sources. > > > and Fabio’s most excellent rewrite of the spectool code (if you > > have > > not used it yet, try it, it’s good). However someone needs to add > > lookaside or buildsys integration to spectool to spectool so > > spectool > > has something to source new sources from in a restricted build > > context. > > Let me just state my opinion that I don't like this situation coming. > Packaging should be simple task, and should be made simpler, obvious. I understand. There is just this huge pressure in npm, and go and rust, and all other modern languages, and even in git itself via submodules, to create huge dependency graphs of interlinked components. You can attempt, like we (me at least) to make individual component packaging as easy and cheap as possible. That still costs you one spec file per git repo, and forces you to treat git submodules as separate projects. It is possible the pressure will continue to grow to a point that a spec needs to automate not just the top-level component but all the other bits upstreams hide bellow this component. If that happens we will need dynamic sourcing in spec files. There is huge pressure EL side at least to get this second scenario to work (in part, due to EL management putting hard constrains on introduction of new srpms, forcing EL packagers to stuff as many things as possible into existing spec files). The requester is clearly attempting the second approach. 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
