F21 System Wide Change: Headless Java

Wed Nov 20 22:22:49 UTC 2013

----- Original Message -----
> From: "Toshio Kuratomi" <a.badger at gmail.com>
> To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
> Sent: Wednesday, November 20, 2013 11:46:32 PM
> Subject: Re: F21 System Wide Change: Headless Java
> 
> On Wed, Nov 20, 2013 at 01:39:48PM -0500, Aleksandar Kurtakov wrote:
> > 
> > The thing is this is pointless. If the people that would do most of this
> > auditing (Java SIG) do not agree with such scenario the result would be
> > that old Require:java will be kept whenever full java jvm is used as this
> > keeps compatibility, ease of cooperation with other distros and so on.
> 
> In fedora we do our best to figure out what the best course of action is and
> then we execute that.  This often involves constructive criticism where
> people raise potential issues and then everyone looks for ways to address
> those issues.
> 
> So if I'm reading this right, what you want to enable is for people to
> install the third-party provided jdk and uninstall the Fedora OpenJDK and
> then be able to install their Fedora application packages on that
> environment.  In order for that to be done without the Fedora OpenJDK being
> dragged in, the idea is that the application packages can only Require:
> things that are also provided by these third party packages.  The third
> party packages already have a virual provide for java and a virtual provide
> for java-headless.  They do not have a virtual provide for
> java-x11/gui/equivalent.
> 
> Is that correct?

No. What I want most is Fedora srpms to stay usable for Mageia/Mandriva guys to import them and build in their build systems.
They do have their own jvm builds which I never cared about as we collaborate pretty well on the things sitting on top of the JVM.
So no, I do not want to let people install other JVMs and use them on Fedora I speak about SRPMs and rebuilding them here.

> 
> Note that in the past, Fedora policy has been that Fedora does not control
> what and how third parties package so it's usually not a good idea to write
> packages to accomodate things in third party repos if it keeps Fedora from
> making better packages.  But with that in mind, there's two angles that we
> can work on to show that accomodating third party packages is a good idea in
> this case.
> 
> Angle 1) more information about the costs of the second virtual provide:
>   - Do you have links to the third party jdk packages that are providing
>     java-headless and java  and not providing java-x11/gui/etc?  Are we
>     talking about a few alternate jdks or many?  or just the most important
>     one (The one from Oracle)?  This would help to show how widely the
>     virtual provides will affect other packages.
>   - Do you have some information about how many people are uninstalling
>     Fedora's openjdk package and installing these alternate jdk packages in
>     their place?  This would help to show how widely people are actually
>     going to be inconvenienced by the difference in virtual provides.
> 
> Angle 2) Reduce the benefits of the second virtual provide
>   - Propose alternate means of tracking what packages have been audited and
>     found to actually need full java.
>     - If the target is mainly new maintainers of the package in question,
>       then Requiring that Requires: java have a comment in the spec file to
>       say that the package really does need the graphical portions of java
>       to be installed may be sufficient.
>     - If the target is to keep an updated list of what packages are yet to
>       be audited, propose something like Virtual Provide in the packages
>       that depend on java.  So if you have java-foo that Requires: java and
>       you have audited the package to know that the requirement is real, add
>       Provides: java-x11-needed to the package.  Then scripts can take the
>       set of packages that Require java and do not Provide java-x11-needed
>       to generate an up to date list.

The more important question to me is why this needs to be tracked? Tracking and collecting information that noone looks at is pointless. 
I opened FE-JAVASIG bug long ago hoping that people will help us fight issue, it doesn't happen. 
Now the two angles are kind of irrelevant with me not looking to switch openjdk in fedora and not planning to look into such tracking information. 
Tracker bugs don't mean anything, it's goals that people set themselves - and I'm yet to meet anyone else but 2-3 guys that ever package java and think about the whole java ecosystem and not about their own tiny bit. It doesn't have to be perfect, it's better to be as simple as possible so one can get maximum result ASAP and move to proper solution (which java-headless is not at all - it's just a workaround). 
Honestly, I don't think any auditing will happen at all. It's maven and wildfly maintainers that will go and fix stuff here and there to get their packages work in headless environment and that's it.

Alexander Kurtakov
Red Hat Eclipse team

> 
> -Toshio
> 
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct