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 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.
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.
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.
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?
If each of the Perls is a stream of a module, you will put Bugzilla into
a module and let it depend on any of the Perls. User can install any of
the Perls and Bugzilla.
With your proposal Bugzilla packager would have to package Bugzilla
twice: as a normal package for default Perl 5.26 and as a module for Perl
5.30. Then a user would have hard time to select the right combinations of
Perl and Bugzilla. It would double fork work pacakgers and and make
the system more dificult for users.
With my proposal, Bugzilla packager would package Bugzilla in
non-modular Fedora unless they also want to package it as a module. If
I see correctly, this is exactly the case today.
And do you know the packager does not want to pacakge Bugzilla as
a module? Because in current Fedora without default streams in build
root he had to package it and maintain it twice.
No, I don't. But I know there are packagers of applications who don't want to do
that. And we should make a distro-scale decision whether we want the whole
distro to work this way, or whether we only allow this - and those who choose to
modularize will do so in addition to the non-modular default packages, not instead.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
