[packages/rpm-pld-macros] 2.058; try to get stable java environment (javadoc binaries etc)
Arkadiusz Miśkiewicz
arekm at maven.pl
Tue Apr 21 11:56:40 CEST 2026
On 20/04/2026 12:53, Jan Palus wrote:
> On 20.04.2026 12:33, Arkadiusz Miśkiewicz via pld-devel-en wrote:
>> On 20/04/2026 12:17, Jan Palus wrote:
>>
>>>> diff --git a/macros.java b/macros.java
>>>> index 2c2ef21..80f1bca 100644
>>>> --- a/macros.java
>>>> +++ b/macros.java
>>>> @@ -66,9 +66,10 @@
>>>> %use_default_jdk() %{expand:%%global use_jdk %{default_jdk %{?*}}}
>>>> # expands to the value with right jdk for BuildRequires header
>>>> -# 'jdk' if %%use_jdk is not defined, jdk(%%use_jdk) otherwise
>>>> -# The requirement will not replace current 'default' JDK
>>>> -%required_jdk jdk%{?use_jdk:(%{use_jdk})}
>>>> +# When %%use_jdk is set, require full JDK package (with /usr/bin/javac etc.)
>>>> +# to ensure correct JDK tools are in PATH when multiple JDK -base packages
>>>> +# are co-installed.
>>>> +%required_jdk %{?use_jdk:%{use_jdk}-jdk}%{!?use_jdk:jdk}
>>>
>>> Please don't. This was specifically designed not to rely on PATH for any
>>> java stuff but to use non-conflicting *-base-* packages and JAVA_HOME
>>> instead.
>>>
>>> This change is the reason java-xalan failed today.
>>>
>>> If there is an issue with some package I'm even willing to help with
>>> packaging rather then going back to "BuildRequires: jdk" and packages
>>> having all sorts of kinky ClassDataVersion because one time jdk11 was
>>> required for libreoffice and another time jdk23 for eclipse-jdt.
>>
>> What's the correct approach?
>>
>> Don't remember which but some package called javadoc binary in build process
>> and despite %use_default_jdk 8 it used javadoc from some openjdk 2X (as all
>> openjdkXX were installed)
>>
>> How to make sure that desired paths are set and correct tools are used
>> without having to audit every call in build system of such package?
>>
>> (some of these could be building fine but still using incorrect binaries (vs
>> use_default_jdk setting)).
>
> It would be best if you could provide some example but in short java
> world settled on using JAVA_HOME and invoking tools from $JAVA_HOME/bin
> so ie $JAVA_HOME/bin/javadoc. There might outliers of course but I'm
> happy to look at those cases even if I don't care about the package
> myself (like I already did on many occasions).
I think it was this package:
https://buildlogs.pld-linux.org/index.php?dist=th&arch=x86_64&ok=0&name=java-gnu-mail&id=b32ecb3c-d948-4cff-8bae-33dfdbb51f00
>
> In terms of packaging it usually boils down to 3 parts:
> 1. %{use_default_jdk} macro which sets preferred jdk version
> 2. %buildrequires_jdk macro which effectively puts a BR on one of
> non-conflicting openjdkX-jdk-base packages
> 3. Passing down %{java_home} in %build in package dependant way. Sometimes
> it's "export JAVA_HOME=%{java_home}", sometimes "%configure
> --with-java-home=%{java_home}" and sometimes it's passing direct paths
> to binaries "%configure JAVAC=%{java_home}/bin/javac"
Maybe some %javawhateverprepareenv to put into %build and/or %install to
setup proper PATH etc?
> To be completely honest I would even prefer if all of
> openjdkX-(jdk|jre)$ packages were forbidden on buuilders.
Could be added to ignore in builders poldek conf (I guess we have no
other way to blacklist packages on builders).
Like ignore = openjdk*-jdk openjdk*-jre?
--
Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )
More information about the pld-devel-en
mailing list