Le vendredi 09 novembre 2018 à 18:44 +0100, Dridi Boukelmoune a écrit : > > > For the Go case (and we can include Rust too) it is indeed very likely > that, because the model is almost exclusively static linking, a leaf > package will force the creation of dozens of devel packages only for > the sake of BuildRequir'ing them. What about changing guidelines to > allow such packages to have multiple SourceX archives and list their > dependencies as bundled(xxx) in the final RPM? That does not work because bundled code is in a terrible state, multiarchive rpms suck to create and maintain, and you lose all the version tracking framework rpm provides (that Go upstream, has not managed to replicate yet in their own package maintainer BTW). What works is to make rust or Go package creation and review as simple and streamlined as possible, so packagers can focus on upstream's poor code state, instead of fighting rpm or the review process. That's basically what https://pagure.io/fesco/issue/2004 and https://github.com/rpm-software-management/rpm/issues/104 are for the technical parts: automate away the mapping between language- specific dep mecanisms and rpm dep mecanisms, so packagers can work on what those dep mean technically not how to rewrite language deps in rpm deps, and they are helped not hindered by the rpm layer. For the org part the review process needs a major rework so it does not provide incentives to publish one frankenpackage that mixes lots of unrelated stale unaudited lumps of code, over several dozen of clean modular packages that are easier to maintain and audit and can be shared between leaf users. And if you want packagers that ignore upstream’s code state, you'll eventually get huge highly publicised security holes. Code does not self-maintain. Regards, -- Nicolas Mailhot _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx
