Matthew Miller wrote:
> Sure, that's fair. Here's the goal: users will have more options
> without exponentially increasing work for packagers and
> distro-creators.
The exponential number of combinations will still exist, it will just be out
of our, or really anybody's, control. It is impossible to test the
exponential number of module version combinations.
And as evidenced in the next point, due to module version conflicts, users
can actually end up with FEWER options than before.
And the tighter you set the module version requirements in inter-module
dependencies to work around the first issue, the worse the second issue
becomes.
>> That destroys the possibility to install all Fedora packages on all
>> Fedora spins, which the shared Everything repository guaranteed. With
>> Modularity fully implemented, you can end up being unable to install KDE
>> Plasma on the GNOME Workstation or the other way round (at least without
>> resorting to containers) because the desktops depend on conflicting
>> versions of some library module. How is that an improvement?
>
> That scenario clearly isn't an improvement, but it's also an edge case.
I do not see installing multiple desktops as an edge case. Sure, it might
not be the common case, but it is still very frequent. It is often desired
as soon as the computer has more than one user, and even a single user may
want to try out another desktop without uninstalling his/her primary desktop
environment.
> Anecdotally, I see "I want KDE without all this GNOME stuff" more than
> I see "I want all these desktops installed at once".
Yet, Fedora does not actually provide that, only Kannolo does. :-)
> But, in any case, yes, that's a tradeoff. The upside is that we'll be
> able to scale up in ways we can't otherwise.
Such as?
> And it means that desktops _do_ have the flexibility to have conflicting
> libraries where that is beneficial.
But that is a major disservice to our users. There is a reason that such a
solution was ruled out for the Fedora 15 NetworkManager conflict.
(Unfortunately, the solution that was implemented also sucked. The late NM
0.9 change should have been rejected instead.)
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
