On Mon, Sep 27, 2021 at 9:09 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > * Christopher: > > > My main point here was that treating the community as a single SIG > > makes no more sense than treating all packages whose software is > > written in C as a single "C SIG" community. It's too overwhelming for > > people to be able to know how to step in and help. > > I'm not sure this is actually true. Debian has Python and Perl > packaging teams which are quite successful, and the Java packaging may > also be in better shape there. > > I think the difference to C is that these languages come with their own > packaging/build systems, so creating a distribution package needs a > certain number of kludges, but once you've figured those out, you can > maintain a large number of packages. I thought that Java used to be > like this, too, thanks to ant and later Maven, but maybe this has > changed with Gradle, SBT, and whatnot. Yeah, there's good tooling support for packaging software that uses ant and maven. And ant and maven themselves will also continue to be maintained by Mikolaj, as far as I know. Projects that use "pure" ant or maven to handle their dependencies and build are *very easy* to package for Fedora, probably even easier than some standard C or Python packages. And the resulting binary packages are also very similar to how Python works (except that Java packages only ship compiled bytecode and no sources). But as you guessed, there's no such support for gradle, sbt, bazel, or whatever new build system Google has been cooking up recently. Nor is there support for Groovy (no longer available in Fedora, as it depended on gradle), Kotlin (was never packaged), or Scala (no longer available) - all of which are now dependencies of gradle. Oh, fun. While gradle *used* to be available as an option for Fedora Java packages, recent versions of gradle are a barely-open-source mess that apparently only upstream itself manages to build from source, and everybody else is supposed to "just build with internet access and use our binary JAR, it's fine (TM)". Another problem is projects that use ant or maven, but do horrendous, nonstandard things *within* those build systems, either with custom ant targets, or weird maven plugins. Maintaining packages that do this sort of thing is very tedious and error-prone, because you as the package maintainer need to keep all the weird "undo this unspeakable upstream horror" changes in sync for new upstream versions. And if upstream decides to port their project from maven to gradle (as some have recently done), then good luck with forward-porting the old maven pom.xml files to new versions. I'm sorry if I sound overly negative here. But the fact that 1) using maven is actually not terrible for making RPM packages, 2) packaging tools for Java are actually pretty comprehensive, but still 3) upstream projects are increasingly doing non-standard things making tools in 1) and 2) obsolete and packaging a very frustrating experience, makes me sad. But since most upstream projects stance is to "just download the JAR we built for you from Maven Central, why are you even looking at our source code, ewww", that is unlikely to change. But I'm not sure if that really fits the FOSS definition any longer, either. Fabio _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
