On Wed, Nov 13, 2019 at 1:34 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > > Aleksandar Kurtakov wrote: > > Here you seem to be missing the third option packager may choose - > > maintain none of them and say bye to Fedora. Which IMHO is the most likely > > outcome of all this. > > "Say bye to Fedora" is what I am going to do if this forced modularity > madness is not going to stop, and I will be taking my 51 packages with me. > > A distribution that does not allow me to install 2 completely unrelated > applications just because they happen to transitively depend on different > versions of some library deep in the stack is entirely useless to me. > You keep repeating this statement as if I haven't said several times now: "If you have a library that can be installed in parallel, make a compat package. Modularity is not the correct solution for that case". You don't want to do that for libraries in general. Rather, it makes more sense if you need to swap out a framework of tightly interdependent packages. (Node.js or Django would be reasonable examples here). Another example that would make sense is... KDE. Instead of doing a mass-upgrade in the middle of a release, you could make the Plasma Workstation packages into a module with KDE release number as the stream. Then people could switch voluntarily to the next version if they want to do so mid-release or they can wait until an upgrade to the next release moves them over. Now, I realize we have some technical issues that prevent you from doing this today (the previously-acknowledged upgrade bugs). But if those were fixed, wouldn't it be *really convenient* to update the packages and then kick off a single build that would build for all active Fedora (and/or EPEL) releases? You'd only need to manage the single module build of all the components once, rather than a build per-component for each release you want to support. That's the usability goal we're working towards in Modularity. We've had a bit of trouble hitting our target for ease-of-use, but that's mostly because we encountered more edge-cases (and resistance) than we expected and have thus been dealing with the higher-priority issues first. _______________________________________________ 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
