> 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@xxxxxxxxxx> wrote: > > 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 _______________________________________________ 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
