[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:       Nicolas Mailhot via devel <devel () lists ! fedoraproject ! org>
Date:       2019-11-16 18:23:17
Message-ID: 4ab4379012a379023948b66c38ce36906f461bcb.camel () laposte ! net
[Download RAW message or body]

Le samedi 16 novembre 2019 à 19:05 +0100, clime a écrit :
> On Sat, 16 Nov 2019 at 18:54, Nicolas Mailhot via devel
> <devel@lists.fedoraproject.org> 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@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.
> > 
> > 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@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]