Dne 13. 11. 19 v 21:48 Stephen Gallagher napsal(a): > 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". The problem is that no matter how often you said this, there will come inquires such as: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/O4NZVLFCZAUMPGGJ5ALM5X33MN2L7PPQ/ And this is probably still good case, because the intention was unveiled on ML. There will be others which will sneak into Fedora unnoticed. Vít > > 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 _______________________________________________ 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
