On 2019-11-15, Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > On 15. 11. 19 16:11, Petr Pisar wrote: >> On 2019-11-15, Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: >>> On 15. 11. 19 14:32, Petr Pisar wrote: >>>> On 2019-10-04, Miro Hrončok <mhroncok@xxxxxxxxxx> 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@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
