Le samedi 16 novembre 2019 à 19:05 +0100, clime a écrit : > On Sat, 16 Nov 2019 at 18:54, Nicolas Mailhot via devel > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Le samedi 16 novembre 2019 à 18:42 +0100, clime a écrit : > > > 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. > > > > Yes it is wickedly cool as a distributed building solution. > > > > It is not cool *at* all* as a replacement for spec declarations. > > Just > > put the correct variables in the spec files themselves, and have > > the > > distributed building solutions set them during builds (as is done > > for > > dist) > > Yes, but the point is, the product of the distributed build should be > a single > rpm so that you don't need to handle two kinds of objects during > installation time and inter-dependencies between them. Really, this is the kind of technical choice that made modules fail in practical terms. Just generate rpms with no magic except a module marker. If you build n versions of a rpm, generate n rpms. Autoreqs will register what you built against (and if they do not allow to disambiguate different versions of the same object they should be fixed). Choosing to source a particular rpm in a particular module should not be more than a user hint. The packages themselves, should just be packages as usual. Mass rebuilds are cool because the user does not need to know that the resulting packages were built by a single all-encompasing build command (usually, several releng iterations as problems are found and fixed). Modules, has they exist today, leak build command grouping into install grouping. That's why the install part of modules is breaking right and left. 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
