F21 System Wide Change: Headless Java

[Stanislav Ochotnicky]

Quoting Richard W.M. Jones (2013-11-16 10:13:33)
> On Sat, Nov 16, 2013 at 02:34:00AM +0100, Miloslav Trmač wrote:
> > On Fri, Nov 15, 2013 at 12:28 PM, Jaroslav Reznik <jreznik at redhat.com> wrote:
> > > == Scope ==
> > > Proposal owners:
> > > * Modify javapackages-tools package to automatically generate "java-headless"
> > > autorequires (simple change)
> > > * Identify and file bugs for affected packages (repoquery and bugzilla bug
> > > creation)
> > > * (optional) Mass-change spec files that have "Requires: java" to "Requires:
> > > java-headless"
> > 
> > What about packages that do requires the non-headless dependencies?
> > Can they be identified automatically, or would "other developers" be
> > required to manually revert the change back from java-headless to full
> > java?
> 
> Wouldn't it be better to inspect the *.class files to find out what
> other classes they depend on.  Then you could have automatically
> generated Perl-style dependencies like:
> 
>   Requires: java(java.net.URL)
> 
> Or if that results in too many dependencies, then at least inspect the
> *.class files to find out if the package only needs the java-headless
> classes.
> 
> (I'm aware it's possible for Java programs to dynamically create and
> load classes.  The same is true for Perl programs but that doesn't
> stop the automatically generated requires being useful most of the
> time.)

I am quite certain rel-engs and RPM maintainers would love us for that. Just
rt.jar from OpenJDK has over 18000 class files. Do we really want an rpm with
18000 provides? Could we even handle it? And that's just tip of the iceberg
really...We have a database of all class files in Fedora. I believe it was over
half a million classes. I wouldn't be surprised if we'd double current metadata
size...

We already generate requires/provides based on Maven metadata which are far more
accurate than anything Perl has (based on my chats with Perl maintainers). We
also require correct minimal version of JRE. But any action we'd take wrt java-headless
would be inaccurate and mostly confusing. Incomplete automatization is worse
that no automatization. People will rely on it and it *will* fail.

I believe OpenJDK maintainers will agree that automatically detecting if java or
java-headless is supposed to be required is not really feasible. There's too
many variables at play.

I'd expect out of ~800 packages that BR java only very few are going to be
affected by java-headless change (i.e. they'd have to revert the change). I'd
estimate maybe 30 broken packages and some we know wouldn't work so we would
exclude them.

How about this:
    * I file bug for every package that BRs java
    * We'll give maintainers two weeks (or maybe a month) to look at the bug and
      possibly fix their packages. 
    * If they don't take any action on the bug (i.e. leave it in NEW)
      we'll fix up the package in automated way.
    * If they close the bug or assign it to themselves we'll leave the package
      alone

However I am worried some maintainers will close those bugs without even
glancing at their packages. And it takes just one screwed up package which pulls
in full java and we're back at square one. I am open to suggestions on how to
allow maintainers to opt-out if they feel confident their package is OK.

-- 
Stanislav Ochotnicky <sochotnicky at redhat.com>
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com