Hi, First of all a big thank you to everyone involved in the discussion for the constructive discussion.
I agree that the situation around java packaging is quite worrying and I'm happy to see that people are trying to come up with a pragmatic solution to the current deadlock situation. On 9/11/20 10:16 AM, Mikolaj Izdebski wrote: <snip>
Modularity provides not only a different way of grouping or delivering RPM packages, but most importantly, a different way of building RPM packages.
<snip> Allow me zoom in on some of the examples you give here. I realize they are just examples but maybe we can extract some patterns from them and come up with solutions to allow you to maintain the and and maven stacks inside the ursine package collection, without increasing your workload.
You get a side tag in Koji where you can have private build-only dependencies that are discarded (filtered) once they are no longer needed, after module build is done. For build-only packages most of security vulnerabilities are not exploitable easily, or at all, therefore are low-severity, which greatly limits maintenance work required to address them. For example, if upstream tests are ran on an obsolete, 12-years old version of Tomcat, I don't need to skip tests, but I can package old Tomcat and run the tests. I don't need to update that Tomcat or fix security issues as they are not exploitable in buildroot - Tomcat runs in embedded mode, does not listen on the network etc. Not something that I could with ursine Tomcat packages - it would get delivered to users, and we have no control how they use it - we would need to fix all important user-reported bugs and CVEs as they are potentially exploitable.
So for this tomcat needed for testing problem, I'm thinking that we might solve this in a very non Fedora way. Why not bundle the old tomcat-sources with the sources which need it for their test-suite (and build it before running the tests). I realize that this is ugly; and if many packages need this old tomcat it will not scale (but I hope that is not the case). Despite those disadvantages I believe that this would be a good solution. The reason why I'm thinking in this direction is as follows: Like others, I'm very much against the notion of buildroot only packages, esp. the side-tag idea is terrible as it makes rebuilding the package from source very hard for end users. To me Fedora would not be Fedora if users can easily rebuild their packages. Bundling the old tomcat sources, so that the test-suite can run, without that old tomcat ever getting installed on the users system, to seems like a decent workaround for the issue of the tests depending on this old tomcat.
Another, more concrete example: core Ant doesn't have any dependencies beyond JDK. It is easy to build and maintain, yet very functional. On the other hand, full Ant with all the optional tasks depends on more than 200 Java packages. For the purpose of building all packages that I am interested in, core Ant with JUnit tasks (total of 3 packages) is sufficient. Functionalities of Ant like sending emails or image processing are obviously not needed in this case. If building other packages is the only use of Ant then it can be maintained much more easily (3 instead of ~250 packages). But when Ant is ursine package in Fedora then it should be the full Ant - we can't claim to deliver Ant to users while it is just part of it. Eclipse in Fedora requires full Ant too.
So if you say that you only need the minimal Ant, and I guess many packages only need the minimal Ant to build, then why not have an ant-minimal package, like we have a vim-minimal ? Now I guess that vim-minimal and "proper" vim are both build from the same source-rpm; and normally we never allow 2 srpms with the same upstream sources in them. But I think that in this case we could make an exemption where there is a separate pkg-git and srpm for an ant-minimal which you would maintain. And then the community / java-sig can maintain the full Ant as I believe is already happening since we do have an ant packaged in Fedora 33 atm. I hope that these 2 examples show that at least in some cases we may be able to come up with creative solutions for the problems involved in java packaging. ### An other more generic approach which has been brought up once or twice, but which not really has been discussed in much detail yet I believe is creating a fedora-builddep repository. ATM a normal user has 3 ursine Fedora repos installed: fedora fedora-updates fedora-updates-testing (disabled by default) What if we add a 4th repo called fedora-builddep: fedora fedora-updates fedora-updates-testing (disabled by default) fedora-builddep (rolling (within a release), disabled by default) So the idea is that all the maven deps which you need, but do not want to offer any end-user support on would go to fedora-builddep. Taking Fedora 33 as an example then: 1) The fedora-33-buildroot pkg-set would consist of fedora-33 + fedora-33-updates + fedora-33-builddep 2) When you build a newer package in the fedora-33-builddep tag (which uses the fedora-33-buildroot) it will automatically get added to the fedora-33-builddep compose right away, that is what I mean with fedora-builddep being rolling. I think that this gives you the builddep only packages which you want, while still allowing end-users to easily rebuild things (users only need to enable the -builddep repo). Then the main thing which we need on top of this is to very clear communicate what sort of expectations users can have wrt support and esp. wrt security updates from packages in the builddep repo and make sure that that message comes across. We will of course need to define some procedures surrounding this: 1. Packages in fedora-x + fedora-x-updates may not have any runtime deps on packages in fedora-x-builldep is the most obvious ones 2. We will need a small procedure for moving packages from fedora-x + fedora-x-updates to fedora-x-builddep, so that they get removed by dnf for people who do not have fedora-x-builddep enabled. Basically a builddep version of the fedora-obosolete-packages metapkg. But lets not get too much into details right now. Mikolaj do think that having such a fedora-builddep repo (combined with e.g. ant-minimal for the "API packages" part of things) could work for you ? Regards, Hans _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
