[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 2:38:38
Message-ID: CAGqZTUvULoY9Z81KhzTMvGGMeJohk+K-VxA7P40q6h82yUCOTg () mail ! gmail ! com
[Download RAW message or body]

> 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 which can be built
distributively and that contains parts which are then inserted
into the standard resulting spec file, which can contain
multiple applications or a just single one. "Stream" can
be a new rpm property that could be used by user as
an extra-specifier during installation. In other words,
modularity should be all about build-time. In the end,
standard rpm should be the result. That way, there
are no collisions between modular and non-modular
on the user side because everything is rpm in the end
and only the way the rpm was produced differs.

On Fri, 15 Nov 2019 at 19:11, Petr Pisar <ppisar@redhat.com> wrote:
>
> On 2019-11-15, Miro Hrončok <mhroncok@redhat.com> wrote:
> > On 15. 11. 19 16:11, Petr Pisar wrote:
> >> On 2019-11-15, Miro Hrončok <mhroncok@redhat.com> wrote:
> >>> On 15. 11. 19 14:32, Petr Pisar wrote:
> >>>> On 2019-10-04, Miro Hrončok <mhroncok@redhat.com> wrote:
> >>>>> Wouldn't it be easier if the "default stream" would just behave like
> >>>>> a regular package?
> >>>>>
> >>>>> I can think of two solutions of that:
> >>>>>
> >>>>> 1. (drastic for modular maintainers)
> >>>>>
> >>>>> We keep miantaining the default versions of things as ursine packages.
> >>>>> We only modularize alternate versions.
> >>>>>
> >>>> Big con:
> >>>>
> >>>> That effectively bans modules with multiple dependencies where at least
> >>>> one is a default version.
> >>>>
> >>>> Example: I have Perl 5.26 as a default version. I have Perl 5.30 as an
> >>>> laternative version. Now I want to package Bugzilla that's written in
> >>>> Perl. How do you package Bugzilla so that it works with Perl 5.26 as
> >>>> well as with Perl 5.30?
> >>>
> >>> I don't understand why would the user care about the Perl version when
> >>> they want Bugzilla. How is Bugzilla different form e.g. Slic3r (app
> >>> that happens to be written in Perl)? Do we want to modularize all such
> >>> apps to solve the "no parallel instability" feature?
> >>>
> >> I don't know. Ask the user why he needs a different Perl version than
> >> the default one.  Maybe he has some other applications that work only
> >> with that particular version.
> >
> > What I was implying is that I don't understand why the user of Buzgilla wants
> > different Perl version to run it. I was not implying that users don't want
> > various Perl versions generally.
> >
> If the user is interested only in Bugzilla and nothing else, then of
> course he does not care about Perl version. Unfortunatelly people run
> more applications on their systems and then they have multiple
> requirements that can conflict each to other.
>
> >> If you believe that users do  not care about a version of software they
> >> use, then we can drop out modularity, and all Fedora releases and
> >> deliver only Rawhide. Or we can stop integrating new versions of
> >> software and deliver Fedora 32 and nothing else forever.
> >
> > I believe that the purpose of a distribution is to cerate and
> > integrated environment, where we simply make sure that Bugzilla works
> > and runs on a Perl version we support. And we move forward and
> > integrate with newer Perl versions.
> >
> I understand. I also don't care about versions until my system is
> compatible and supported. But the problem emerges when you start to care
> because you need a new feature or postpone an upgrade because the new
> version is broken for you.
>
> > Note that I don't necessarily mean that the use case doesn't exist,
> > I just say I don't really get it. And why is Bugzilla any different
> > that all other Perl applications.
> >
> Bugzilla is not any different. It was only an example.
>
> > Either the strategy should be:
> >
> > "We offer alternate Perl versions for containers etc. they conflict
> > with the default Perl version and with the non-modular apps. That is
> > known and accepted."
> >
> > Or the strategy should be:
> >
> > "We build all our Perl applications for all our Perl versions, so
> > users who choose their Perl stream can still keep their applications
> > from the distribution."
> >
> > I fail to see what are we trying to achieve here exactly.
>
> I would love this second option, but with current modularity it's not
> feasable. Not because of the juvenile defects we have now (like
> switching streams on distribution upgrades) but because it would require
> a module for each package. And current implementation does not scale so
> well and cannot describe all needed relations we have readilly available
> on an RPM level. A true solution would be blending modularity into RPM.
> At build time as well as at installation time.
>
> So the first option is more realistic. You correctly write "alternate
> [...] versions [...] conflict [...] with the non-modular apps".
>
> However, my intuition says that nobody will use the alternative versions
> for exactly this reason. And I think I'm right. Look at me. I maintain
> Perl modules but I don't use them. I cannot because I would have to
> uninstall all the other Perl packages from my system. And not only Perl
> packages. fedpkg transitively depends on non-modular Perl. Anybody who
> wants a different Perl cannot be a Fedora packager.
>
> Therefore I think it's desirable to modularize applications. Because
> that way we diminish the conflicts and that increases value of the
> distribution. Look how few modules we have now in Fedora.
>
> Now you can think another modularity fatatic who wants to modularize
> everything and have all modules in multiple versions. Not at all.
> I believe most of the modules will exist only in one stream. But
> the reason why we need to modularize everything is to actually enable
> multiple stream for the "few" modules that actually can take benefits
> from the multiple streams. Because once everything is a module, it's
> trivial to add a new stream to a module in a middle of the dependency
> tree. It's trivial to test the new stream. Any user can enable it and
> test it how it works on his system.
>
> But as I wrote, this is probably not doable with current modularity
> (modules above packages). I'm sorry, I write to much.
>
> > It was said several times that parallel instability is a non-goal of
> > Modularity and that means certain apps won't install if certain
> > streams are selected. Or did I get that wrong?
> >
> This problem is parallel availability. If you do not build, let's return
> to examples, Bugzilla for all available Perls, the user will have no
> choice.  Once he needs Bugzilla he cannot select Perl version. That's
> what I don't like.
>
> -- Petr
> _______________________________________________
> 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]