On Sat, Dec 7, 2019 at 2:57 PM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > 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. (snip) > 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. I agree - Modularity (at least, in its current incarnation) has made it way too easy to make mistakes (whether on purpose or by accident), with no good way to undo the damage once they have been pushed to end users. Fabio > 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 _______________________________________________ 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
