Hi Mikolaj, On Fri, 2018-07-13 at 15:30 +0200, Mikolaj Izdebski wrote: > On 07/13/2018 11:00 AM, Severin Gehwolf wrote: > > See this bug for some background: > > https://bugzilla.redhat.com/show_bug.cgi?id=1600426 > > > > Any Java package gets a "Requires: javapackages-tools" whether they > > want it or not. It's part of the Java Packaging Guidelines[1]. Does > > anybody remember the rationale as to why that exists? If the answer is > > directory ownership for dirs like /usr/lib/jvm/ et.al. I'd consider > > changing the guidelines to auto-requires javapackages-filesystem in > > F29+. > > Typically packages require javapackages-tools during runtime for one or > both of two following major reasons: > > 1. Directory ownership. javapackages-tools requires > javapackages-filesystem, which owns many directories into which Java > packages install their files. > > 2. Java functions library. javapackages-tools contains library of shell > functions at /usr/share/java-utils/java-functions which is imported by > application launcher scripts written in shell. These functions may be > used to help loading system-wide or application-specific configuration, > constructing application classpath, determining proper JVM/JDK to use > with the application, and finally invoking JVM with appropriate flags, > including ABRT agent flags, and finally invoking JVM. > > (There are also other minor, but valid reasons to require > javapckages-tools, such as for configuration files it contains.) > > Changing auto-requires from javapackages-tools to > javapackages-filesystem and rebuilding all packages would break most of > launcher scripts. Explicit requires on javapackages-tools would have to > be added to packages that have launchers in order to fix them, reverting > some of benefits of the change. [...] Some data points from a rawhide query from today. A) Total packages with "Requires: javapackages-tools": 4204 B) Total packages with "Requires: javapackages-tools" that are *not* -javadoc sub-packages: 2991 C) Total packages with "Requires: javapackages-tools", not a -javadoc sub-package and installing something in {,/usr}/bin: 145 > Implementing this change would require modifying many Java packages to > add explicit requires to spec files. It would not affect users of Java > applications, which would still need to require javapackages-tools. It > would only possibly affect installations with Java libraries, but no > applications, provided that these libraries don't have dependencies on > applications. Given from the data above it would entail to change on the order of 145 (binary) packages[1]. I've also run specific analysis on those 145 packages in order to figure out whether or not they source /usr/share/java-utils/java- functions from javapackages-tools. It appears there are (roughly) 82 SRPM packages which may need changing[2]. 5 of those already use explicit requires for javapackages-tools[3]. Note that this doesn't seem to capture packages like ant. ant itself doesn't depend on javapackages-tools, but it depends on ant-lib which does. Yet, the ant package installs binaries which use functions exported by javapackages-tools, not ant-lib. There is also a case of installed symlinks like for package eclipse-platform which symlinks to ant. While eclipse-platform is a false positive, ant is a false negative. > So to me it seems like a lot of effort for not much benefit. But I'm not > opposed to the change, as long as people implementing it will take > responsibility for fixing all packages broken by it. Due to nature of > the change, affecting many packages across the distribution, I think it > should be a system-wide change approved by FESCo. If you think a system-wide change is needed for this, then so be it. I'll help get packages fixed and get explicit javapackages-tools requirement added for the packages that need it. Given that there are currently about 80 SRPM to potentially change, it seems a reasonable effort. After all, all other packages will benefit from the change. Thanks, Severin [1] See attachment "bin_containing_packages_javapackages_tools.txt" for a list of specific binary RPM packages. [2] See attachment "pkgs_needing_javapackages-tools_srpms_name.txt" [3] console-image-viewer eclipse gradle liquibase will-crash
389-console CardManager HdrHistogram Mars OpenStego accumulo-core accumulo-gc accumulo-master accumulo-server-base accumulo-tracer accumulo-tserver antlr-tool antlr3-tool antlr4 antlrworks apache-rat-core aqute-bnd batik-rasterizer batik-slideshow batik-squiggle batik-svgpp batik-ttf2svg bindex bolzplatz2006 bsh bundling-detection-java byteman checkstyle clapham clojure closure-compiler colossus console-image-viewer dbus-java derby ditaa dl_poly-gui dtdinst ecj eclipse-cdt eclipse-cdt-tests eclipse-platform eclipse-tests elasticsearch findbugs fop freecol freerouting gherkin2-java gogui gradle gradle-local hadoop-common hadoop-hdfs hadoop-mapreduce hadoop-yarn hdfview hive icedtea-web imagej itext-rups jabref jarjar java-deptools java-shogun java-wakeonlan javacc javadocofflinesearch javahelp2 javapackages-local jaxodraw jcuber jdiff jenkins-cli jets3t-app jetty jflex jgit jibx jing jmake jmol josm jpanoramamaker jruby jsonld-java-tools jtidy junit5 jython lcm-java legendsbrowser liquibase log4j-jmx-gui logisim maven-lib metadata-extractor2 modello msv-msv msv-rngconv msv-xmlgen mvel nekohtml nesc neurord objectweb-asm objectweb-asm3 ohc-benchmark pki-console pki-tools plantuml portecle portmidi-tools proguard proguard-gui rachota rhino sablecc sbt scala shiro-tools-hasher sunflow svnkit-cli taggle taggle-server thermostat tika-app tomcat tomcat-lib tonto trang tuxguitar voms-clients-java weka will-crash woden-tool xerces-j2 xjparse xml-commons-resolver xmvn-bisect xmvn-install xmvn-resolve xmvn-subst yuicompressor zanata-client zookeeper
389-console accumulo antlr antlr3 antlr4 antlrworks apache-rat aqute-bnd batik bolzplatz2006 bsh bundling-detection-java CardManager checkstyle clapham closure-compiler console-image-viewer derby ditaa eclipse fop freecol freerouting gherkin2-java gogui gradle HdrHistogram itext jarjar javacc java-deptools javadocofflinesearch javahelp2 java-wakeonlan jdiff jenkins jetty jflex jing-trang jmol josm jpanoramamaker jsonld-java-tools jtidy junit5 legendsbrowser liquibase log4j logisim Mars maven metadata-extractor2 modello msv mvel nekohtml neurord objectweb-asm3 objectweb-asm ohc OpenStego plantuml portecle proguard rachota rhino scala shiro sunflow svnkit tika tomcat tonto weka will-crash woden xerces-j2 xjparse xml-commons-resolver xmvn yuicompressor zanata-platform
_______________________________________________ java-devel mailing list -- java-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/java-devel@xxxxxxxxxxxxxxxxxxxxxxx/message/WVZOI7I27SAOUVF2SGCRLGVPEFFHXGWP/
