Matthew Miller wrote: > Core-Extras was a bad ideas because Core was developed inside Red Hat > in a non-open way and did not allow community involvement beyond that > of beta testing. Merging it all together was probably the only > realistic way to fix that (and fixing that was absolutely the best > thing to do), but if we'd kept separate repos, we'd have addressed the > technical problems sooner and had a lot more of the flexibility that we > _really_ need to keep growing. That was only one aspect of the problem. The bigger issue is that packages routinely had to be built without some features because the package was in Core and the feature would have required something from Extras (an issue we are still seeing with RHEL and EPEL nowadays), packages had to be brought from Extras to Core as dependencies, and in some cases, packages actually had to be moved from Core to Extras to be able to use dependencies from Extras. This issue is now coming back with the modules. Some packages also actually had to be split into 2 SRPMs from the same sources, one in Core and one in Extras, instead of using subpackages, due to build-time requirements on Extras packages. (One example was the package I got sponsored with: redhat-artwork-kde, split out from redhat-artwork as part of https://fedoraproject.org/wiki/Archive:UnleashKDE – I maintained that for 2 weeks, then the Core-Extras Merge happened and it was already obsolete. ;-) That was an interesting start of a packager career. ;-) ) Having a unified Everything repository from which individual binary packages can then be picked from is a huge advantage. It is just too common that you have things such as: * optional plugin subpackages requiring extra dependencies to build. You want to build the package with those dependencies, then split the plugins into subpackages so that the main runtime package can be installed without those dependencies. But with the module isolation, you cannot do that anymore. * documentation requiring huge toolchains such as LaTeX to build, but not to view. * dependencies required only for the test suite, as in the autotools case. In addition, having a unified end of life makes system maintenance A LOT easier for the users. I consider the whole concept of modularity fatally flawed by design. You are about to eat the cake and to not realize that you will not have it anymore then. The feature's promise that you can eat your cake and have it too is impossible to fulfill. Kevin Kofler _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
