Hi Fabio,
On 05-08-19 13:37, Fabio Valentini wrote:
On Mon, Aug 5, 2019 at 1:15 PM Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> wrote:
On Mon, Aug 5, 2019 at 12:07 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
In the extended version: https://churchyard.fedorapeople.org/orphans-2019-08-05.txt
I see that javapackages-tools is still on the list (because it depends on gradle)
and that in turn brings problems for lot of other packages.
So I wonder what the plan forward is. I've been looking at my own packages
which depend on javapackages-tools and they really only need 2 things:
From my side as owner of javapackages-tools the plan is to do nothing
as there is no problem with javapackages-tools packages (that I know
of). If at some point of time javapackages-tools becomes FTBFS or FTI
due to gradle or another of its dependencies being retired, I will fix
the problem in an adequate way.
1) javapackages-filesystem
2) %jpackage_script macro (and it deps)
Looking at: https://fedoraproject.org/wiki/Packaging:Java this is pretty much
the minimum set of what packages need to follow the guidelines. It seems that
javapackages-tools contains way more then this and I'm wondering if it would
be a good idea to do a javapackages-tools-minimal as a separate package and
move the 2 items from above there. Then over time we can move java-packages
in the base package set to use javapackages-tools-minimal and eventually drop
the full javapackages-tools from the base package set.
I don't see any reason to add javapackages-tools-minimal or migrate
any packages. If there are any issues with javapackages-tools then
please open bugs and I will respond to them.
To clarify, the package that *does* depend on a number of orphans is
gradle, which also marks javapackages-tools and its sub-packages as
affected.
gradle is currently owned by the Stewardship SIG, but there is no
reason for us to "maintain" it indefinitely. In fact, the gradle
packaging is problematic in some ways:
- the version packaged by fedora (and every other distro building it
from source) is really outdated (4.4.1, released Dec 2017, vs. 5.5.1,
released July 2019)
- the build process is rather involved, and gradle currently can't
even build itself
Only about 10 "active" fedora packages are built with gradle, and they
could be ported to use maven instead. There's already some fedora
packages which are built with maven "downstream" instead of with the
upstream gradle build system - including junit5, testng, and
aqute-bnd.
So, I am currently preparing to drop gradle after f31 was branched
from rawhide (but keep it working in f31), unless somebody else steps
up to maintain gradle and the dozens of dependencies it pulls in. If /
when gradle support is eventually dropped, then we'll then have to
remove gradle-local from javapackages-tools as well (which is easy,
since that change already happened in modular branches).
Thank you for all your work on this I'm happy to hear that the
gradle -> javapackages-tools -> lots of packages dep chain is
going to get fixed for F31.
I do wonder though if the modular version of javapackages-tools has
already dropped gradle-local, perhaps we can move ahead and already
do the same thing in Fedora (31+)? Less cross package deps seems like
a good thing to me? But I guess that some other packages in the base
repo still depend on gradle-local?
Regards,
Hans
_______________________________________________
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
