On Tue, 8 Oct 2019 at 15:32, John M. Harris, Jr. <johnmh@xxxxxxxxxxxxx> wrote: > > We could simply stop doing projects that throw wildly different versions of software into a single installation, which causes this issue. > We could also just all quit and join potato farming cults.. they are next to the Yak farms which we seem to be shaving on this since 1997. The issue has been the same since before we combined Core and Extras together.. how do you get N amount of software for M different needs with Y number of contributors. When Y is growing or has a large influx of people to replace short time contributors.. you can make N large. When it isn't because people either found a different solution to their problem or just don't find OS sexy at the moment.. you have to make N smaller. However in making N smaller, you also end up making M smaller which will negatively affect Y. You just hope you choose the right N's which will make M still large enough that Y minimizes to a positive value. > On October 8, 2019 6:23:47 PM UTC, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: >> >> On Tue, Oct 08, 2019 at 02:09:24PM -0400, Przemek Klosowski via devel wrote: >>> >>> Having said that, I am not sure it will solve the problem with >>> ecosystems requiring specific collection of component versions (*): >>> what is the expected number of required versions for each module in >>> those environments? If it is much more than 2 then fast/slow scheme >>> might not work. >> >> >> Yeah, I don't think modularity solves this well at the individual component >> version explosion of doom. Ideally, we'd get developers to not do that, but >> ... we've tried that for 25 years with less and less success over time. >> >> I mean, really, nothing we're doing really solves this. >> >> So... I think the solution there is really: automated bundling, >> automated detection of that bundling, and where possible, automated >> patching. But that's _another_ major project. >> > > -- > Sent from my mobile device. Please excuse my brevity. > _______________________________________________ > 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 -- Stephen J Smoogen. _______________________________________________ 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
