[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Modularity and the system-upgrade path
From:       clime <clime () fedoraproject ! org>
Date:       2019-11-16 17:42:04
Message-ID: CAGqZTUufm+7eqPridEPnYU1-dtNU7X2dV8Ewn5vK6-G1PCnqbg () mail ! gmail ! com
[Download RAW message or body]

On Sat, 16 Nov 2019 at 08:38, Nicolas Mailhot via devel
<devel@lists.fedoraproject.org> 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@lists.fedoraproject.org
> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
> 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@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org

[prev in list] [next in list] [prev in thread] [next in thread]