On Sat, 16 Nov 2019 at 08:38, Nicolas Mailhot via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Le samedi 16 novembre 2019 à 03:38 +0100, clime a écrit : > > > A true solution would be blending modularity into RPM. > > > At build time as well as at installation time. > > > > I agree this would be the best. Basically, final > > product of a module build should be an rpm. modulemd > > file should be kind of a meta-spec file > > There should be no need for a modulemd *at* *all*. modulemd + related infrastructure gives you distributed building, which is cool if you want to build a "solution" i.e. multiple software packages all combined to serve a particular use-case. Also passing compile time option to tweak the given build is allowed by modulemd. You don't get something like that when building a spec file and i think it would be hard to achieve. > > Specifying a module stream target for a build should be just an rpm > variable, in ~/.config/rpm/macros or passed on the cli to rpmbuild, > etc. > > Exactly like we do with dist. We managed to handle multiple > distribution releases with dist, even if it was not a core rpm concept, > without needing to change rpm at all. And it works. And it didn't cause > half the havoc of modules. > > Sure, do some rpm fixing if necessary so the result feels less like a > kludge than %dist. But, don’t rely on an external framework to do > things for you instead of doing the necessary work (if any) at the > component format level. > > Module upgrade and conflict resolution strategies should be just dnf > modules over this basic rpm format. So we can have change the strategy > over time without changing the packages and specs themselves. > > And *then*, you can build all kinds of templating management frameworks > over those basic format changes. In fact people being people they will > build multiple frameworks, in all kind of languages, and argue > endlessly which one is best. That won’t matter because the low-level > module info and format will exist directly in rpm. > > Modules started with the end-user management framework (porcelain) > part, and got lost somewhere trying to decide how to map it to low > level concepts. That, does not work. Start from fundations before > arguing about the roof decorations. > > 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
