On 07/13/2018 03:55 PM, Severin Gehwolf wrote: > 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. > > Question is how many of the Java packages use javapackages-tools for > 2). Any ideas how we'd figure this out in some automated way? Should be easy. Check packages that require javapackages-tools and check if their executable files import /usr/share/java-utils/java-functions. > >> Lets look at case of byteman, mentioned in the bug. Switching >> auto-requires to javapackages-filesystem would not achieve much, as >> byteman ships launcher scripts in /usr/bin/ that require >> javapackages-tools to function properly, so explicit requires on >> javapackages-tools would probably need to be added. Moreover, byteman >> requires objectweb-asm, which also contains launcher script and >> therefore would still need to require javapackages-tools for reason nr >> 2. above. > > Not really. byteman does not use what you describe as 2) from > javapackages-tools. That's just upstream functionality. Byteman also > doesn't require objectweb-asm (at runtime; its BR only), so that's not > good of an argument either. It would run fine with just java-openjdk > (JDK 10). Right, byteman does not use java-functions library. After I checked its file lists wrongly assumed it followed packaging guidelines for launcher scripts, but it does not. Also from what I can see byteman does require objectweb-asm during runtime, but this is probably a bug as byteman bundles ASM, IIRC. $ dnf -q --repo rawhide repoquery --requires byteman | grep asm mvn(org.ow2.asm:asm) mvn(org.ow2.asm:asm-analysis) mvn(org.ow2.asm:asm-commons) mvn(org.ow2.asm:asm-tree) $ dnf -q --repo rawhide repoquery --whatprovides 'mvn(org.ow2.asm:asm)' objectweb-asm-0:6.2-1.fc29.noarch >> For the auto-requries to have desired effect many packages >> would need to be split into library and application parts. Like for >> example, maven binary package contains only launcher script (plus >> manpage and bash completion associated with the script), while maven-lib >> contains library code. > > Perhaps that would be a change for the better? Perhaps. -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk _______________________________________________ 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/FGH6RSAKSJ4SJZZEHNO32CJZJA62T7ZE/
