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