Re: javapackages-tools auto-require: Why?

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

 



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.

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

> Thoughts?

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.

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.

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




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

  Powered by Linux