F21 System Wide Change: Headless Java

[Toshio Kuratomi]

On Wed, Nov 20, 2013 at 03:04:16PM +0100, Stanislav Ochotnicky wrote:
> 
> So which one of them would "Provides: java"? I'll give you several variants:
> 
> headless provides java:
>     - breaks compatibility expectations of older/3rd party RPMs
>     - we suddenly switch every Java package in Fedora. No opt-out
> 
> meta package provides java (and requires both headless and x11 version):
>     - doesn't change anything because you can't "yum remove java-meta" or "yum
>       remove java-x11" (due to packages having "requires: java" which is
>       satisfied by this metapackage.  And no, packages cannot have "Requires:
>       java-1.7.0-openjdk[-meta]" because there are usually multiple
>       implementations of java in Fedora. We'd be changing buildrequires every
>       few releases.
> 
> x11 version provides java:
>     - That's basically what current proposal is with addition of metapackage.
>       But I fail to see the point of metapackage in this scenario
> 
The meta package should provide java.  I actually think that the meta
package providing java is closest to what the current proposal is minus the
metapackage.  Unless I'm misunderstanding the current proposal, as long as
packages Require: java but could really just need headless then there is no
change from the status quo.  It isn't until packagers modify their Requires
to java-headless that we see benefits.  So the benefit arrives at the same
time as it would with a metapackage.

Note -- If I'm reading you right and then remembering the trickiness of the
multiple-jdk's.... The Provides: java may be the equivalent of the
metapackage currently.  What's really missing is a Provides: java-x11 type
package.  That way packagers can mark that their package really does require
the gui bits.

> 
> Then again I might be completely missing the point of the metapackage but I've
> been trying for past day (on and off) to come up with situation where it would
> help without causing multiple other issues (or at least backward
> incompatibility) and failed... So if you can explain it, or give a better
> example how you think it should work: I'd love to be wrong.
> 
> > > I can see one advantage to this approach: it lets us tell packagers that
> > > Requires: java should no longer be used.
> 
> I don't consider that an advantage. It breaks backward compatibility for...I
> don't know. I don't mind Fedora being different. But if we diverge from
> conventions it would be great to have a *good* reason. 
> 
It doesn't break any backwards compatibility.  It gives us a deprecation
route.  ie: Requires: java works but we're telling people not to use it.

> > > Packagers should determine whether
> > > they're using APIs that require X and either Requires: java-x11 or Requires:
> > > java-headless based on what they really need.  We can then audit the
> > > packageset at a later date to determine which packages haven't adjusted
> > > their Requirements yet
> 
> So what is stopping us from auditing the package set with current non-x11
> proposal? There will be bugzillas, it will be easy to see which packages were
> automatically converted to headless, which were supposedly fixed by their
> maintainers and then just go through them. And at any later point in time
> "repoquery --whatrequires java" will give you a list of packages that need to be
> audited if they can be migrated to headless.
> 
Ease.  Querying bugzilla to find out if the package really shouldn't be
using Requires: java is a broken idea.  Firstly, it depends on mass filing
bugs against everything that Requires: java to have the maintainer evaluate
whether X11 support is needed even if it's obvious that the package does.
Second, it requires that we file bugs for every package that Requires: java
that enters the repository after the mass filing so that we have a record in
bugzilla of whether the package intends to use it or not. Thirdly, scraping
bugzilla for this information seems like a lot of work compared to using
repoquery.

So then, what's the advantage in repoquery?  If the packages that need X11
support continue to use Requires: java, there's no way to differentiate
a package which needs X11 from a package which has not been audited.  So
repoquery --whatrequires java will always return packages to you and then
you'll have to tromp through bugzilla or some other external list of
packages to decide whether you need to audit the package or if it's already
been checked.  Migrating people to java-headless and java-x11 would mean
that you know everything has been audited when "repoquery --whatrequires
java" returns aero packages.

> What *could* be done is add additional provides "java-x11" to main OpenJDK
> package and then have packagers explicitly change to either headless or x11
> version. I am not entirely sure what we'd achieve with this though (besides
> making sure someone has looked at the spec and modified it).  If we migrate all
> packages to either java-x11 or java-headless those RPMs lose compatibility with
> older Fedoras, RHELs etc. Inevitably %if macros will be creeping in and...what
> for? So that we can say: "Yes, we have looked at the spec file". 

Yep, as noted above, I think a second virtual Provide would serve the same
purpose as a metapackage in this case.  As noted above, I don't think we
agree on the things you previously mentioned as disadvantages.  The
conditionals would be a cost.  However, for me the benefit in being able to
easily tell whether a package is using the correct dependencies outwieghs
that.  And there's definitely precedent in Fedora to have backwards compat
conditionals -- Remember the GCJ Guidelines having to coexist with new java
guidelines for instance.  Condiionals for a single Requires: are extremely
easy and non-intrusive by comparison.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20131120/32b72d65/attachment.sig>