Re: javapackages-tools auto-require: Why?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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:
>>> 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/ 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

$ dnf -q --repo rawhide repoquery --whatprovides 'mvn(org.ow2.asm:asm)'

>> 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?


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:
List Guidelines:
List Archives:

[Index of Archives]     [Red Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux