[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:       Petr Pisar <ppisar () redhat ! com>
Date:       2019-11-15 18:10:44
Message-ID: slrnqstqh4.jjv.ppisar () dhcp-0-146 ! brq ! redhat ! com
[Download RAW message or body]

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

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