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




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

  Powered by Linux