On Wed, Nov 13, 2019 at 3:49 PM Stephen Gallagher sgallagh@redhat.com wrote:
On Wed, Nov 13, 2019 at 1:34 PM Kevin Kofler kevin.kofler@chello.at 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".
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.
Could we have those parts without the module mangling bits? Having a definition to orchestrate the creation of the SRPMs, then order them correctly for a chain build, then push them into a defined side-tag would be glorious. Making it so that works across multiple releases for the same commit would be nirvana.
Then we'd be talking about a reduced form of the yaml that controls the creation of side-tags, builds the RPMs into there, then lets you use the output side tag as an input for submitting a large update to Bodhi.