On Thu, Oct 24, 2019 at 10:40 AM Igor Gnatenko <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:
This basically makes modularity not useful for many things:
1. People will have to have different workflows between "default"
version (standard workflow, as we have today) and "modular" version.
I do not think so. If modularity was an opt-in, then people could consume the default non-modular
content and only switch to modules when they wanted to solve a specific problem. Those specific
problems were in the beginning to be slower or be faster than the normal Fedora would be.
Also that means, on the distribution upgrade maintainers will have to
do many things to remove modular stream, add old one and upgrade
non-modular version.
The packagers would probably maintain one non-modular version for each Fedora release
and other versions in modules, if they liked to.
This is also not only about maintainers, but end
users too:
FXX: fish 3.x is non-modular, stream 4.x exists
FXX+1: fish 4.x is non-modular, stream 3.x exists
This is not what I'd expect. I would rather like:
FXX: fish 3 is non-modular, streams 3, 4 exist as modules
FXX+1: fish 4 is non-modular, streams 3, 4 exist as modules.
From the users' perspective, if I did not care about the fish version and I only wanted fish, they would do dnf install fish which
will result in non-modular content. If someone wanted a specific version of the fish, they might do dnf module install fish:3
which would result in a modular fish, of the same version, but this version would stay on the system as long as the user would switch
manually.
If fish:3 became EOL, DNF would say something like: The fish:3 stream does not have a follower in the new Fedora release,
what to you want to do:
a) switch to a non-modular default (version 4)
b) switch to a different modular stream (fish:4)
c) switch to a different modular stream (fish:5)
* Nobody can guarantee that those will be compatible
Very true. So we should probably be very much aware of this, because if we cannot maintain compatibility between single
modular streams, how do we maintain compatibility across all the modules, default or non-default, in a typical desktop
environment of Fedora?
Or wait, is modularity still the food for containers as advocated in the beginning? Then we do not have to worry about compatibility
too much, because once you want to switch to a different stream, just create a new container.
2. In Rust we use modularity to build bunch of packages, filter
buildroot-only packages and ship only one user-facing RPM. If we
remove default stream, people won't be ever able to do `dnf install
ripgrep'. This is worst UX we can provide.
If DNF said, in this case, something like The package you are trying to install is only available as a module,
please use dnf module install ripgrep to install it. -> I do not see that as the worst UX at all. On the contrary, this
is a clear message to the user that he should either go modular (with everything it brings) or forget about that package.
The choice remains in their hands.
The problem is that we don't have
well-defined *user* experience.
Agreed 100%.
After last few years with modularity, I don't think it is improving
but it definitely causes some problems.
> _______________________________________________
> 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
--
Lukáš Růžička
FEDORA QE, RHCE
Purkyňova 115
612 45 Brno - Královo Pole
_______________________________________________ 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
