Re: Modularity and the system-upgrade path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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*.

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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux