On Wed, Oct 16, 2019 at 7:58 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > > Stephen Gallagher wrote: > > An awful lot of people are repeating this as if it's a solution > > without understanding the existing architecture. Believe it or not, > > attempting to abandon default streams and go back to only non-modular > > content available by default is a lot harder than it sounds (or should > > be, but I noted that we're working on that in another reply elsewhere > > in the thread). There is currently no path to upgrades that would get > > back from the modular versions and the closest we could manage would > > be to rely on the dist-upgrade distro-sync, but in that case we > > *still* need to have DNF recognize that the default stream has changed > > (in this case, been dropped) and handle that accordingly. > > So completely disable all module support in DNF by default with some global > flag (make all the module code conditional under some new enable_modules > flag and default the flag to enable_modules = 0), then it will treat the > packages as normal packages and you only have to provide a higher EVR. All > this module processing should only happen if the user explicitly enables it. > Given that many of the modules in the distribution currently are there specifically to provide newer, less-stable versions of the versions in the non-modular/default stream, this would be fairly disastrous. For example, Node.js 10.x is the default stream in Fedora 30 because it's the LTS branch. It also provides a non-default stream for 8.x (the previous LTS branch that a lot of applications still rely on) and 12.x, which will be the next LTS branch in November, but is not guaranteed stable yet. With the approach you're describing, everyone would be forcibly updated to the unstable 12.x release. The only way we could assure ourselves that this wouldn't happen would be to do another mass-rebuild, bumping the epoch of every package that exists in a module. That's a lot of work. > A slightly more elaborate, but slightly harder to implement, approach would > be to let DNF simply disable modules that are enabled locally but no longer > available in the repositories, together with disabling the fedora-modular > and updates-modular repositories by default. > And again, this only works if every packager who has spent time creating a module with a default stream takes their content and shoves it back into the non-modular repository. Which in some cases they probably cannot do, because they have build-dependencies that are in conflict. This is a highly non-trivial process and it would need to be done individually for every single package. That's far more packager-hostile than fixing the default stream/buildroot problem and the upgrade path problem. > And the case of demodularizing packages has to be addressed sooner or later > anyway, so better address it sooner rather than later, before more and more > damage is done by maintainers moving packages to module-only without a way > back. > I've already acknowledged upthread that demodularizing packages is a problem we need to solve. It's being worked on, but it's a lot harder than you think, because we have failsafe code implemented in libdnf to prevent *accidental* demodularization that's in conflict with this desire. Also, this paragraph was needlessly antagonistic: moving packages to modules is not "damage". > > I started this discussion to ask the community to help us identify the > > best path *forward*. An endless barrage of "kill it off" replies is > > not helpful or productive. If anyone has specific advice on how to > > move forward (or, indeed, if you can figure out how to migrate back > > without considerable release engineering and packager effort), that > > would be productive. Just please keep in mind that we have to go to > > war with the army we have, not the one we wish we had. > > If you are standing in front of a cliff, moving forward is just not the > answer. Not all changes are improvements. Sometimes, you have to realize > that you made a mistake and move back before things only get worse. > Sure, but we are nowhere near a cliff. As I just posted in the Change Proposal thread, there are three problems we need to solve, two of which we already have solutions designed for and one (this thread) that we are trying to finalize. That's far from "standing in front of a cliff". Please understand that "I don't understand how this works" is not the same thing as "This doesn't work". > The overwhelmingly negative feedback that you are getting is a clear > indication that something is wrong. You should not ignore it or summarily > file it off as luddites wanting to return to the past. There are real issues > with modules, and the Modularity WG is only offering partial workarounds > (adding more and more complexity) and no real fixes. > So, literally every word of this is wrong. The negative feedback is not "overwhelming". It is approximately four noisy individuals, all of whom have expressed zero interest in understanding the actual situation that they are trying to "fix" by endlessly insulting the people working on the problem. Demoralizing the people who can dig us out of this situation is an unwise strategy. Also, we're not offering "partial workarounds" (excepting some acknowledged hackery to avoid blocking F31). All of the proposals I have been discussing in this thread are for real design adjustments for long-term benefit. And while they add some additional complexity on the *infrastructure*, a primary goal is to not make the users or packagers' lives harder. We *know* that the default stream/buildroot issue is failing to hit this goal and the solution is known, implemented upstream and could be deployed by the end of the week if FESCo gives its approval. > I have provided above 2 possible approaches to address the "migrating back" > issue. No, you've decided on the outcome you want to see and have invented a path to get there that doesn't align with the realities of the present. _______________________________________________ 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
