On Fri, Dec 06, 2019 at 08:18:21PM -0500, Langdon White wrote: > ## How to determine if you have an issue and how to fix it: > > run: ```sudo dnf list --installed *protobuf*``` > if you get a result that looks like > ```protobuf.x86_64 3.6.1-6.module_f31+6793+1c93c38``` > > you have encountered the problem. so please: > > run: ```sudo dnf module disable eclipse``` > run: ```sudo dnf downgrade protobuf``` > > Any updates, as of a few hours ago, should be fine. > > ## What happened: > First and foremost, this issue appears to be caused by Modularity but, in > fact, is just an example of a policy not being followed. This is correct, but at the same time imo very short-sighted. Look at it this way: setting the eclipse module as default was discussed in the FESCo issue tracker and in IRC meetings for about two months. I think that this particular stream had undergone scrutiny that is _way above normal_. The requests for additional information in the FESCo ticket were overruled. Despite that when it gets enabled things go south and require manual workarounds. It seems that introspectability of modules is not good and even the people who designed Modularity can't do the required checks. Now let's imagine that we don't have just a handful of streams, most of them very trivial, but a few hundred, including some that build complicated dependency trees, with actual multiple versions of dependencies. Nobody will have the time or energy to do introspection, so those kinds of issues will go undiscovered until reported by users. How often would such issues occur, e.g. a few hundred times per year? For this it doesn't really matter if the modules are default or not: either enabled as a default or explicitly by the user, modules *will* override other packages they shouldn't, sometimes by mistake, sometimes on purpose as a result of a disagreement between maintainers. With modularity, any module owner has effectively *higher* privileges than owners of packages, because modules override non-modular builds. Why do I think this is more of a problem with modules? Right now we have an elaborate and long-established system with maintainers, co-maintainers, proven packagers, and mass changes, i.e. some formal and some customary rules as to what can be done to packages of other maintainers and who is "at fault" with any given bug. Modularity throws this system out the window and replaces it with ... nothing. Zbyszek _______________________________________________ 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
