On Wed, Nov 13, 2019 at 4:01 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > 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. I'm wondering what you mean by "module mangling bits" here, because what you described here is pretty much *exactly what module builds do*. _______________________________________________ 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
