----- Original Message ----- > From: "Zbigniew Jędrzejewski-Szmek" <zbyszek@xxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Saturday, December 7, 2019 2:55:30 PM > Subject: Re: modular protobuf issue (Dec. 6, 2019) recap > > 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 > Exactly. It might be a policy issue, but I haven't seen any checks in place to ensure that the policy is being followed. The only way to figure out a policy violation is being reported by someone if at all. And if as a module maintainer want to override non-modular rpm's by accident or maliciousness on stable systems, now I get that capability with modularity. -- Regards, Charalampos Stratakis Software Engineer Python Maintenance Team, Red Hat _______________________________________________ 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
