On Sat, 16 Nov 2019 at 08:38, Nicolas Mailhot via devel
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,
> 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.
> Nicolas Mailhot
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: