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?
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.
--
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