On Wed, Nov 13, 2019 at 3:49 PM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > On Wed, Nov 13, 2019 at 1:34 PM Kevin Kofler <kevin.kofler@xxxxxxxxx> 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
