On Thu, Sep 10, 2020 at 12:12:05PM -0400, Robbie Harwood wrote: > Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> writes: > > On Thu, Sep 10, 2020 at 3:46 PM Alexander Scheel <ascheel@xxxxxxxxxx> wrote: > >> Hi Joe, > >> On Thu, Sep 10, 2020 at 8:52 AM Joe Orton <jorton@xxxxxxxxxx> wrote: > >> > I'm writing as the Red Hat engineering manager responsible for Maven and > >> > Ant in RHEL, and on behalf of Mikolaj Izdebski and Marian Koncek from my > >> > team. I want to give a broad response to some of the points here: > >> > > >> > 1. The team has two missions in Fedora: > >> > > >> > a) We deliver, maintain and support Ant and Maven in Fedora. Our aim is > >> > to provide developers with the most popular Java build systems which are > >> > reviewed, tested, and updated through the release lifecycle. > >> > > >> > b) We design, develop and document tooling that enables anyone to > >> > package Java software with a simple, efficient and scalable process. We > >> > are also active members of Java SIG, collaborating on complex changes > >> > and guiding new contributors. > >> > > >> > 2. We are committed to maintaining the Ant and Maven modules in > >> > Fedora. We have always expected to make them available as default > >> > streams and in the buildroot so they can be available and consumed by > >> > non-modular packages, but we completely respect the decisions of FESCo > >> > to disallow default streams and of other contributors to adopt and > >> > maintain the non-modular packages. We are not going to promise to > >> > commit time and resources to maintain the non-modular packages. > >> > >> As a reminder (as in my RHEL devel-list reply): there are no default > >> module streams in Fedora. There is also no Ursa Major/Prime, so were > >> they to exist, there would still be no way for non-modular packages to > >> use them. > > > > There are default module streams in Fedora 31. > > Fedora 31 is most likely EOL in about two months. I really hope you're > not targeting your future development against it. This exchange summarizes the situation nicely. Modularity can be considered an over-complicated hyped-through-the-roof bundling mechanism. For a long time Fedora has very strongly discouraged bundling in the sense of subsumming one package into another to have a custom build of a dependency. The disapproval of bundling is not because it doesn't work: it does, and in fact with some crappy libraries it's the least bad solution. The disapproval is motivated by the fact that bundling doesn't scale and that it subtracts from the ecosystem. Instead of us all cooperating and each bugfix helping all users of a given dependency, a maintainer of a bundled library is only helping themselves and their package. Bundling is not inherently bad: currently the policy even allows it as a workaround if using the system-wide package is not feasible. It is a pragmatic choice to allow it as a last resort. But the effect of bundling on other packages must be minimized any conflicts or confusion with the system version avoided. With Modularity, we threw this accumulated wisdom away. In two ways: by encouraging private^Wbuild-only dependencies and by letting bundled^Wmodularized rpms shadow normal rpms. For Maven packaging the appeal of Modularity is clearly the privatization of the dependency tree, which obviously undercuts the ecosystem of packages. The Java ecosystem collapsed so quickly because it was already weak — hundreds of packages on the shoulders of one person. But even in a stronger ecosystem, with enough packages modularized, the packaging ecosystem of mutual cooperation would collapse. For some other modules, the appeal is the overriding of package deps, which means that the modular rpms don't have to worry about getting it deps precisely declared, at the cost of breaking the deps declared in other packages. If there wasn't Modularity and instead Maven would bundle it's deps into one huge srpm, the effect on the ecosystem would be the same. As with bundling, Modularization gives short-term relief at a very high long-term cost. We should avoid modularization like we avoid bundling. Zbyszek _______________________________________________ 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
