F21 System Wide Change: Headless Java

[Jaroslav Reznik]

= Proposed System Wide Change: Headless Java  =
https://fedoraproject.org/wiki/Changes/HeadlessJava

Change owner(s): Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;

Server installations of Fedora should usually not pull in packages related to 
X system or sound subsystem. For this reason part of OpenJDK package has been 
split into headless subpackage which has smaller dependency chain. Fedora 
packages should be migrated to require java-headlesss instead of full java 
package when appropriate.

== Detailed description ==
OpenJDK package in Fedora has been traditionally monolithic, pulling in a lot 
of dependencies including (but not limited to)

* libXrender
* libXi
* libXtst
* pulseaudio 

This is obviously not optimal for minimal server installations where OpenJDK 
is used for web application development and deployment.

Designed after Debian packaging, Fedora OpenJDK package has been split into 
packages providing java and java-headless. This makes it possible for packages 
to use "Requires: java-headless". For most libraries and generic packages this 
is sufficient. End-user applications should keep "Requires: java" to pull in 
full OpenJDK package.

This change aims to convert most Java packages to have "Requires: java-
headless" when appropriate. BuildRequires on java-devel are unaffected. 

== 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" 

Other developers:
* Modify spec files to have "Requires: java-headless" instead of "Requires:

java"
* (note) JavaSIG has several proven packages that could assist with this 
change 

Release engineering:
* mass rebuild is not necessary but it would simplify things 

Policies and guidelines:
* Packaging:Java needs to be modified to account for java-headless package 
existence (Note: there is already a packaging draft that aims to do that among 
other changes) 

_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Reindl Harald]

thank you!

Am 15.11.2013 12:28, schrieb Jaroslav Reznik:
>  = Proposed System Wide Change: Headless Java  =
>  https://fedoraproject.org/wiki/Changes/HeadlessJava
>  
>  Change owner(s): Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
>  
>  Server installations of Fedora should usually not pull in packages related to 
>  X system or sound subsystem. For this reason part of OpenJDK package has been 
>  split into headless subpackage which has smaller dependency chain. Fedora 
>  packages should be migrated to require java-headlesss instead of full java 
>  package when appropriate.
>  
>  == Detailed description ==
>  OpenJDK package in Fedora has been traditionally monolithic, pulling in a lot 
>  of dependencies including (but not limited to)
>  
>  * libXrender
>  * libXi
>  * libXtst
>  * pulseaudio 
>  
>  This is obviously not optimal for minimal server installations where OpenJDK 
>  is used for web application development and deployment.
>  
>  Designed after Debian packaging, Fedora OpenJDK package has been split into 
>  packages providing java and java-headless. This makes it possible for packages 
>  to use "Requires: java-headless". For most libraries and generic packages this
>
>  is sufficient. End-user applications should keep "Requires: java" to pull in 
>  full OpenJDK package.
>  
>  This change aims to convert most Java packages to have "Requires: java-
>  headless" when appropriate. BuildRequires on java-devel are unaffected. 
>  
>  == 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" 
>  
>  Other developers:
>  * Modify spec files to have "Requires: java-headless" instead of
> "Requires: 
>  java"
>  * (note) JavaSIG has several proven packages that could assist with this 
>  change 
>  
>  Release engineering:
>  * mass rebuild is not necessary but it would simplify things 
>  
>  Policies and guidelines:
>  * Packaging:Java needs to be modified to account for java-headless package 
>  existence (Note: there is already a packaging draft that aims to do that among 
>  other changes)

[Stanislav Ochotnicky]

Quoting Jaroslav Reznik (2013-11-15 12:28:11)
>  * (optional) Mass-change spec files that have "Requires:
> java" to "Requires: 
>  java-headless" 
>  
>  Other developers:
>  * Modify spec files to have "Requires: java-headless" instead of
> "Requires: 
>  java"
>  * (note) JavaSIG has several proven packages that could assist with this 
>  change 
>  
>  Release engineering:
>  * mass rebuild is not necessary but it would simplify things  
I would like to point out that all of the above could be simply automated. We
have done similar change when we migrated packages from "BuildRequires: maven"
to "BuildRequires: maven-local" and it worked without issues. It will save
precious developer/rel-eng time and ultimately will only break minimal amount of
packages (with simple workarounds and fixes).

-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[Ville Skyttä]

On Fri, Nov 15, 2013 at 2:09 PM, Stanislav Ochotnicky
<sochotnicky(a)redhat.com&gt; wrote:
>  Quoting Jaroslav Reznik (2013-11-15 12:28:11)
> > * (optional) Mass-change spec files that have "Requires: java" to
> "Requires:
> > java-headless"
> >
> > Other developers:
> > * Modify spec files to have "Requires: java-headless" instead of
> "Requires:
> > java"
> > * (note) JavaSIG has several proven packages that could assist with this
> > change
> >
> > Release engineering:
> > * mass rebuild is not necessary but it would simplify things
>
>  I would like to point out that all of the above could be simply automated. 
If you do that, please make sure to not touch packages that have
already been converted -- properly finding out what's already done
will probably require using repoquery, for example due to possible
conditionals in specfiles that make them backwards compatible, e.g.
http://pkgs.fedoraproject.org/cgit/jing-trang.git/commit/?id=6d46e64fe0f3...

[Stanislav Ochotnicky]

Quoting Ville Skyttä (2013-11-15 14:11:37)
>  On Fri, Nov 15, 2013 at 2:09 PM, Stanislav Ochotnicky
>  <sochotnicky(a)redhat.com&gt; wrote:
>  > Quoting Jaroslav Reznik (2013-11-15 12:28:11)
>  >> * (optional) Mass-change spec files that have "Requires: java" to
> "Requires:
>  >> java-headless"
>  >>
>  >> Other developers:
>  >> * Modify spec files to have "Requires: java-headless" instead of
> "Requires:
>  >> java"
>  >> * (note) JavaSIG has several proven packages that could assist with this
>  >> change
>  >>
>  >> Release engineering:
>  >> * mass rebuild is not necessary but it would simplify things
>  >
>  > I would like to point out that all of the above could be simply automated.
>  
>  If you do that, please make sure to not touch packages that have
>  already been converted -- properly finding out what's already done
>  will probably require using repoquery, for example due to possible
>  conditionals in specfiles that make them backwards compatible, e.g.
>
> http://pkgs.fedoraproject.org/cgit/jing-trang.git/commit/?id=6d46e64fe0f3...
Ugh. Why did you have to do that? That commit changed nothing because all the
dependencies still have "Requires: java". Technically speaking you also made a
change which is against packaging guidelines[1], but that's not really an issue
in this case

Unnecessary complications...

[1] https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires

-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[gil]

Il 15/11/2013 14:22, Stanislav Ochotnicky ha scritto:
>  Quoting Ville Skyttä (2013-11-15 14:11:37)
> > On Fri, Nov 15, 2013 at 2:09 PM, Stanislav Ochotnicky
> > <sochotnicky(a)redhat.com&gt; wrote:
> >> Quoting Jaroslav Reznik (2013-11-15 12:28:11)
> >>> * (optional) Mass-change spec files that have "Requires: java" to
> "Requires:
> >>> java-headless"
> >>>
> >>> Other developers:
> >>> * Modify spec files to have "Requires: java-headless" instead of
> "Requires:
> >>> java"
> >>> * (note) JavaSIG has several proven packages that could assist with this
> >>> change
> >>>
> >>> Release engineering:
> >>> * mass rebuild is not necessary but it would simplify things
> >> I would like to point out that all of the above could be simply automated.
> > If you do that, please make sure to not touch packages that have
> > already been converted -- properly finding out what's already done
> > will probably require using repoquery, for example due to possible
> > conditionals in specfiles that make them backwards compatible, e.g.
> >
> http://pkgs.fedoraproject.org/cgit/jing-trang.git/commit/?id=6d46e64fe0f3...
>  Ugh. Why did you have to do that? That commit changed nothing because all the
>  dependencies still have "Requires: java". Technically speaking you also made a
>  change which is against packaging guidelines[1], but that's not really an issue
>  in this case
>
>  Unnecessary complications... 
agree
regards
>  [1] https://fedoraproject.org/wiki/Packaging:Java#BuildRequires_and_Requires
>

[Ville Skyttä]

On Fri, Nov 15, 2013 at 3:22 PM, Stanislav Ochotnicky
<sochotnicky(a)redhat.com&gt; wrote:
> >
> http://pkgs.fedoraproject.org/cgit/jing-trang.git/commit/?id=6d46e64fe0f3...
>
>  Ugh. Why did you have to do that? 
Huh, wow, that's not at all the response I was expecting. What did you
expect to achieve with it?

Anyway, I'll bite: the primary reason is because I've seen earlier
specfile mass modifications (automated as well as done by
non-maintainer humans) happen in a way I don't want to see happen to
packages I maintain. And it's already been a long time since the
availability of java-headless was announced. See also below.

>  That commit changed nothing because all the dependencies still have
> "Requires: java". 
And what do you think will happen when the dependencies get fixed to
depend on java-headless? Oh, these packages don't need any action,
java-headless goodness just is suddenly available with them. So it did
change something after all, no? Progress needs to start somewhere, and
I helped by doing the bits applicable to my packages. Waiting until
their dependency chain gets fixed would have been grossly inefficient;
there was no reason to wait for that, and still isn't.

[Stanislav Ochotnicky]

Quoting Ville Skyttä (2013-11-15 18:30:33)
>  On Fri, Nov 15, 2013 at 3:22 PM, Stanislav Ochotnicky
>  <sochotnicky(a)redhat.com&gt; wrote:
>  >>
> http://pkgs.fedoraproject.org/cgit/jing-trang.git/commit/?id=6d46e64fe0f3...
>  >
>  > Ugh. Why did you have to do that?
>  
>  Huh, wow, that's not at all the response I was expecting. What did you
>  expect to achieve with it? 
Yeah, I guess I should have omitted that first sentence. My apologies. I
consider the rest still valid though

>  Anyway, I'll bite: the primary reason is because I've seen
> earlier
>  specfile mass modifications (automated as well as done by
>  non-maintainer humans) happen in a way I don't want to see happen to
>  packages I maintain. And it's already been a long time since the
>  availability of java-headless was announced. See also below. 
It's been 3 weeks and even in that announcement thread I explicitly mentioned
guidelines not being fixed yet. But you are right, you are entitled to your own
style in your own packages (to a degree). So an opt-out system for automated
changes is probably needed.

>  Waiting until their dependency chain gets fixed would have been
> grossly
>  inefficient; there was no reason to wait for that, and still isn't. 
There's a difference between deps being fixed and fixing all packages at once in
the same way.

>  > That commit changed nothing because all the dependencies still
> have "Requires: java".
>  
>  And what do you think will happen when the dependencies get fixed to
>  depend on java-headless? Oh, these packages don't need any action,
>  java-headless goodness just is suddenly available with them. So it did
>  change something after all, no? Progress needs to start somewhere, and
>  I helped by doing the bits applicable to my packages.  
I don't know what ticked me off. Perhaps because you went seemingly ahead
without any regard for coordinated effort. If you wanted to speed it up, I'd
welcome if *you* created the change proposal and drove it. If you think that 800
packages are going to get fixed by a miracle when some maintainers don't even fix
their packages that break dependent packages you are mistaken. If everyone
just fixed their packages to "Requires: java-headless" at their own discretion
I'll tell you when we'd actually notice the change: never.

I'd like to think that maintainers of those 800 packages are going to actually
make an effort but I know better from past experience. Unless their own package
is broken in serious way they won't care. It's the same in your case really, you
fixed your package so you don't care. But I care about all of those 800
packages. I just start to question why...


-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[Toshio Kuratomi]

On Nov 15, 2013 4:09 AM, "Stanislav Ochotnicky" <sochotnicky(a)redhat.com&gt;
wrote:
>  Quoting Jaroslav Reznik (2013-11-15 12:28:11)
>  > * (optional) Mass-change spec files that have "Requires: java" to
"Requires:
>  > java-headless"
>  >
>  > Other developers:
>  > * Modify spec files to have "Requires: java-headless" instead of
"Requires:
>  > java" 
Could you say a few words about why a java-headless package was chosen
instead of java-x11 (as an example name)?

-Toshio

[Stanislav Ochotnicky]

Quoting Toshio Kuratomi (2013-11-18 17:08:12)
>  On Nov 15, 2013 4:09 AM, "Stanislav Ochotnicky"
> <sochotnicky(a)redhat.com&gt;
>  wrote:
>  >
>  > Quoting Jaroslav Reznik (2013-11-15 12:28:11)
>  > > * (optional) Mass-change spec files that have "Requires: java" to
>  "Requires:
>  > > java-headless"
>  > >
>  > > Other developers:
>  > > * Modify spec files to have "Requires: java-headless" instead of
>  "Requires:
>  > > java"
>  
>  Could you say a few words about why a java-headless package was chosen
>  instead of java-x11 (as an example name)?
>   
I believe the term was chosen because it's widely used term in Java world.
Oracle uses that term in official documentation as well[1]. Last but not least,
Debian uses that term as well and I see no reason to be different just for the
sake of it.


[1] http://www.oracle.com/technetwork/articles/javase/headless-136834.html

-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[Toshio Kuratomi]

On Tue, Nov 19, 2013 at 09:29:40AM +0100, Stanislav Ochotnicky wrote:
>  Quoting Toshio Kuratomi (2013-11-18 17:08:12)
>  > On Nov 15, 2013 4:09 AM, "Stanislav Ochotnicky"
> <sochotnicky(a)redhat.com&gt;
>  > wrote:
>  > >
>  > > Quoting Jaroslav Reznik (2013-11-15 12:28:11)
>  > > > * (optional) Mass-change spec files that have "Requires: java"
> to
>  > "Requires:
>  > > > java-headless"
>  > > >
>  > > > Other developers:
>  > > > * Modify spec files to have "Requires: java-headless" instead
> of
>  > "Requires:
>  > > > java"
>  > 
>  > Could you say a few words about why a java-headless package was chosen
>  > instead of java-x11 (as an example name)?
>  > 
>  
>  I believe the term was chosen because it's widely used term in Java world.
>  Oracle uses that term in official documentation as well[1]. Last but not least,
>  Debian uses that term as well and I see no reason to be different just for the
>  sake of it.
>   
I mean (and sorry that I wasn't clear), why the choice to make java-headless
the special case?  Especially if (as it appears from the reply to Jerry
James), most packages in Fedora will only need the headless version.

(So the headless version would be the java package,  The version with the
gui nevironmen deps would be java-x11 or similar).

-Toshio

[Stanislav Ochotnicky]

Quoting Toshio Kuratomi (2013-11-19 10:49:57)
>  On Tue, Nov 19, 2013 at 09:29:40AM +0100, Stanislav Ochotnicky
> wrote:
>  > Quoting Toshio Kuratomi (2013-11-18 17:08:12)
>  > > On Nov 15, 2013 4:09 AM, "Stanislav Ochotnicky"
> <sochotnicky(a)redhat.com&gt;
>  > > wrote:
>  > > >
>  > > > Quoting Jaroslav Reznik (2013-11-15 12:28:11)
>  > > > > * (optional) Mass-change spec files that have "Requires:
> java" to
>  > > "Requires:
>  > > > > java-headless"
>  > > > >
>  > > > > Other developers:
>  > > > > * Modify spec files to have "Requires: java-headless"
> instead of
>  > > "Requires:
>  > > > > java"
>  > > 
>  > > Could you say a few words about why a java-headless package was chosen
>  > > instead of java-x11 (as an example name)?
>  > > 
>  > 
>  > I believe the term was chosen because it's widely used term in Java world.
>  > Oracle uses that term in official documentation as well[1]. Last but not least,
>  > Debian uses that term as well and I see no reason to be different just for the
>  > sake of it.
>  > 
>  I mean (and sorry that I wasn't clear), why the choice to make java-headless
>  the special case?  Especially if (as it appears from the reply to Jerry
>  James), most packages in Fedora will only need the headless version.
>  
>  (So the headless version would be the java package,  The version with the
>  gui nevironmen deps would be java-x11 or similar). 
If someone wanted to install just OpenJDK for their own in-house Java
application they would have to know to request full -x11 version. I would wager
we'd be receiving a lot of bugs if we went this way. If someone needs headless
they will be actively looking for it. If they want "java" they will not
consider
that they might get incomplete version. Not to mention possible 3rd party RPMs
that might exist

-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[Reindl Harald]

Am 19.11.2013 17:15, schrieb Stanislav Ochotnicky:
> > I mean (and sorry that I wasn't clear), why the choice to
> make java-headless
> > the special case?  Especially if (as it appears from the reply to Jerry
> > James), most packages in Fedora will only need the headless version.
> >
> > (So the headless version would be the java package,  The version with the
> > gui nevironmen deps would be java-x11 or similar).
>  
>  If someone wanted to install just OpenJDK for their own in-house Java
>  application they would have to know to request full -x11 version. I would wager
>  we'd be receiving a lot of bugs if we went this way. If someone needs headless
>  they will be actively looking for it. If they want "java" they will not
> consider
>  that they might get incomplete version. Not to mention possible 3rd party RPMs
>  that might exist 
what about having a "java-1.7.0-openjdk" meta-package obsoleting the existing
one
and pulling *both* but decide if Fedora packages if the headless is enough for
dependencies and so packagers of sevrer software can require this?

this way you would have the least surprise for someone who does not care about
the difference and expects the full one by install "java-1.7.0-openjdk" but
make it really easy to uninstall any graphical dependencies on servers

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/19/2013 11:23 AM, Reindl Harald wrote:
>  Am 19.11.2013 17:15, schrieb Stanislav Ochotnicky:
> >> I mean (and sorry that I wasn't clear), why the choice to make
> >> java-headless the special case?  Especially if (as it appears
> >> from the reply to Jerry James), most packages in Fedora will
> >> only need the headless version.
> >> 
> >> (So the headless version would be the java package,  The
> >> version with the gui nevironmen deps would be java-x11 or
> >> similar).
> > 
> > If someone wanted to install just OpenJDK for their own in-house
> > Java application they would have to know to request full -x11
> > version. I would wager we'd be receiving a lot of bugs if we went
> > this way. If someone needs headless they will be actively looking
> > for it. If they want "java" they will not consider that they
> > might get incomplete version. Not to mention possible 3rd party
> > RPMs that might exist
>  
>  what about having a "java-1.7.0-openjdk" meta-package obsoleting
>  the existing one and pulling *both* but decide if Fedora packages
>  if the headless is enough for dependencies and so packagers of
>  sevrer software can require this?
>  
>  this way you would have the least surprise for someone who does not
>  care about the difference and expects the full one by install
>  "java-1.7.0-openjdk" but make it really easy to uninstall any
>  graphical dependencies on servers
>  
>  
>   
I agree with Reindl here, if I understand him correctly. It would
certainly break upgrades in an unexpected way if an upgrade from
"java-1.7.0-openjdk" suddenly stopped carrying the graphical components.

We did something similar in the SSSD project where we broke up the
standard install into sssd-core and a series of sssd-* plugin
packages. We then created an 'sssd' metapackage that included all of
the plugins, since that was how it used to be shipped.

This allows a user to easily and trivially install the complete suite
(via 'yum install sssd') but if they want to trim down, such as for an
embedded system, they can pick only the components they need.

I think it would be wise to do the same for Java. Create
'java-openjdk-1.7.0-headless' and 'java-openjdk-1.7.0--x11' and then
have the 'java-openjdk-1.7.0' metapackage install both of them.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlKLriUACgkQeiVVYja6o6PHEQCfd7bdLe+yS14b4kiOxFEF8mrx
> UYkAn3pflqngx9SYPQl6lpFtSv+9UotL
> =p3rs
> -----END PGP SIGNATURE-----

[Toshio Kuratomi]

On Tue, Nov 19, 2013 at 01:29:58PM -0500, Stephen Gallagher wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  On 11/19/2013 11:23 AM, Reindl Harald wrote:
>  > Am 19.11.2013 17:15, schrieb Stanislav Ochotnicky:
>  >>> I mean (and sorry that I wasn't clear), why the choice to make
>  >>> java-headless the special case?  Especially if (as it appears
>  >>> from the reply to Jerry James), most packages in Fedora will
>  >>> only need the headless version.
>  >>> 
>  >>> (So the headless version would be the java package,  The
>  >>> version with the gui nevironmen deps would be java-x11 or
>  >>> similar).
>  >> 
>  >> If someone wanted to install just OpenJDK for their own in-house
>  >> Java application they would have to know to request full -x11
>  >> version. I would wager we'd be receiving a lot of bugs if we went
>  >> this way. If someone needs headless they will be actively looking
>  >> for it. If they want "java" they will not consider that they
>  >> might get incomplete version. Not to mention possible 3rd party
>  >> RPMs that might exist
>  >  
<nod>

>  > what about having a "java-1.7.0-openjdk" meta-package
> obsoleting
>  > the existing one and pulling *both* but decide if Fedora packages
>  > if the headless is enough for dependencies and so packagers of
>  > sevrer software can require this?
>  > 
>  > this way you would have the least surprise for someone who does not
>  > care about the difference and expects the full one by install
>  > "java-1.7.0-openjdk" but make it really easy to uninstall any
>  > graphical dependencies on servers
>  > 
>  > 
>  > 
>  
>  I agree with Reindl here, if I understand him correctly. It would
>  certainly break upgrades in an unexpected way if an upgrade from
>  "java-1.7.0-openjdk" suddenly stopped carrying the graphical components.
>   
Note -- I think that the way the feature has things constructed would
achieve something similar.  The java package is essentially java-x11.  It
would Require: java-headless.

So yum install java will get you the java w/X11 support.

[...]
>  
>  I think it would be wise to do the same for Java. Create
>  'java-openjdk-1.7.0-headless' and 'java-openjdk-1.7.0--x11' and then
>  have the 'java-openjdk-1.7.0' metapackage install both of them.
>  
I can see one advantage to this approach: it lets us tell packagers that
Requires: java should no longer be used.  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.

-Toshio

[Reindl Harald]

Am 19.11.2013 20:29, schrieb Toshio Kuratomi:
>  On Tue, Nov 19, 2013 at 01:29:58PM -0500, Stephen Gallagher wrote:
> > On 11/19/2013 11:23 AM, Reindl Harald wrote:
> >> what about having a "java-1.7.0-openjdk" meta-package obsoleting
> >> the existing one and pulling *both* but decide if Fedora packages
> >> if the headless is enough for dependencies and so packagers of
> >> sevrer software can require this?
> >>
> >> this way you would have the least surprise for someone who does not
> >> care about the difference and expects the full one by install
> >> "java-1.7.0-openjdk" but make it really easy to uninstall any
> >> graphical dependencies on servers
> >>
> > I agree with Reindl here, if I understand him correctly. It would
> > certainly break upgrades in an unexpected way if an upgrade from
> > "java-1.7.0-openjdk" suddenly stopped carrying the graphical components.
>  
>  Note -- I think that the way the feature has things constructed would
>  achieve something similar.  The java package is essentially java-x11.  It
>  would Require: java-headless.
>  
>  So yum install java will get you the java w/X11 support.
>  
> > I think it would be wise to do the same for Java. Create
> > 'java-openjdk-1.7.0-headless' and 'java-openjdk-1.7.0--x11' and then
> > have the 'java-openjdk-1.7.0' metapackage install both of them.
> >
>  I can see one advantage to this approach: it lets us tell packagers that
>  Requires: java should no longer be used.  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 
agreed, but with the meta-package nobody is forced to change anything
while any maintainer at any time can say "hey, we do not need the
graphical components and so we relax now the dependencies"

so anybody can point at any time to whatever package and ask for
relax the deps to java-headless and at no point in time any change
is forced since the expierience shows changes can't be forced inside
Fedora - look how long it took to get native systemd-units and there
are still packages with sysv-init-scripts

[Stanislav Ochotnicky]

Quoting Reindl Harald (2013-11-19 23:38:21)
>  
>  
>  Am 19.11.2013 20:29, schrieb Toshio Kuratomi:
>  > On Tue, Nov 19, 2013 at 01:29:58PM -0500, Stephen Gallagher wrote:
>  >> On 11/19/2013 11:23 AM, Reindl Harald wrote:
>  >>> what about having a "java-1.7.0-openjdk" meta-package obsoleting
>  >>> the existing one and pulling *both* but decide if Fedora packages
>  >>> if the headless is enough for dependencies and so packagers of
>  >>> sevrer software can require this?
>  >>>
>  >>> this way you would have the least surprise for someone who does not
>  >>> care about the difference and expects the full one by install
>  >>> "java-1.7.0-openjdk" but make it really easy to uninstall any
>  >>> graphical dependencies on servers
>  >>>
>  >> I agree with Reindl here, if I understand him correctly. It would
>  >> certainly break upgrades in an unexpected way if an upgrade from
>  >> "java-1.7.0-openjdk" suddenly stopped carrying the graphical
> components.
>  > 
>  > Note -- I think that the way the feature has things constructed would
>  > achieve something similar.  The java package is essentially java-x11.  It
>  > would Require: java-headless.
>  > 
>  > So yum install java will get you the java w/X11 support.
>  > 
>  >> I think it would be wise to do the same for Java. Create
>  >> 'java-openjdk-1.7.0-headless' and 'java-openjdk-1.7.0--x11' and
> then
>  >> have the 'java-openjdk-1.7.0' metapackage install both of them.
>  >> 
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


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. 

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

>  agreed, but with the meta-package nobody is forced to change
> anything
>  while any maintainer at any time can say "hey, we do not need the
>  graphical components and so we relax now the dependencies"
>
>  so anybody can point at any time to whatever package and ask for
>  relax the deps to java-headless and at no point in time any change
>  is forced since the expierience shows changes can't be forced inside
>  Fedora - look how long it took to get native systemd-units and there
>  are still packages with sysv-init-scripts 
As stated above, metapackage introduces more issues and doesn't solve any.
You can't migrate your package to headless in isolation. You have to migrate
*all* dependencies for it to have any noticeable effect.

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

Last by not least there would be necessary additions of conditionals into
packaging guidelines.

Can we actually list good reasons to have a metapackage or x11 subpackage that
would outweight the inevitable disadvantages? If you *really* feel I
misunderstood these two ideas we can start an etherpad or something so we can
ping-pong more effectively on specific issues.


-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[Nicolas Mailhot]

Le Mer 20 novembre 2013 15:04, Stanislav Ochotnicky a écrit :

>  Can we actually list good reasons to have a metapackage or x11
> subpackage
>  that
>  would outweight the inevitable disadvantages? If you *really* feel I
>  misunderstood these two ideas we can start an etherpad or something so we
>  can
>  ping-pong more effectively on specific issues. 
What will you do when wayland arrives and you'll need to make the x11
parts optional even for gui apps? That was always the core problem of
SUN's "stuff everything in the default install" approach: it avoids
looking for optional parts, but the base install slowly accrues layers of
not-so-useful and perhaps-deprecated bits.

Regards,

-- 
Nicolas Mailhot

[Stanislav Ochotnicky]

Quoting Nicolas Mailhot (2013-11-20 16:20:34)
>  
>  Le Mer 20 novembre 2013 15:04, Stanislav Ochotnicky a écrit :
>  
>  > Can we actually list good reasons to have a metapackage or x11 subpackage
>  > that
>  > would outweight the inevitable disadvantages? If you *really* feel I
>  > misunderstood these two ideas we can start an etherpad or something so we
>  > can
>  > ping-pong more effectively on specific issues.
>  
>  What will you do when wayland arrives and you'll need to make the x11
>  parts optional even for gui apps? 
Wayland has and for foreseeable future will have an X11 compat layer. As far as
I am aware there is nobody working on native Wayland support in OpenJDK. So the
answer to your question is: I will do nothing because OpenJDK will need X11
libraries.

-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[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

[Aleksandar Kurtakov]

I start to think this conversation goes nowhere. The whole split is superficial and most
java developers are used to get full jvm if they require java.
This would probably change with Java 8 introducing Profiles [1]. And any proper packaging
should be modeled after this one. Inventing even more new names/provided/etc. now would
just increase the mess we already have. 
I remember seeing servlets using awt/ImageIO for image processing on tomcat version
running on headless server - and it was leading just to jvm crash. That was in Java 5
times but illustrates the problem. This was easily fixable by adding
-Djava.awt.headless=true to Tomcat startup scripts, what I want to point with that is that
simply moving a package require java-headless from full java has to be carefully thought
on per package base with some changes done to the packages if needed to ensure no such bad
examples start to pop out. Java means full JVM so we would better not confuse this with
any java-x11(what about wayland coming?) or similar naming at least for now. Also
headless(through the java.awt.headless option) is known and well recognized option in Java
community while x11 would mean nothing to many Java developers. This keeps us closer to
common terms and not deviate needlessly.


[1] http://openjdk.java.net/jeps/161


Alexander Kurtakov
Red Hat Eclipse team

----- Original Message -----
>  From: "Toshio Kuratomi" <a.badger(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Wednesday, November 20, 2013 7:10:56 PM
>  Subject: Re: F21 System Wide Change: Headless Java
>  
>  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
>  
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Toshio Kuratomi]

On Wed, Nov 20, 2013 at 12:27:38PM -0500, Aleksandar Kurtakov wrote:
>  I start to think this conversation goes nowhere. The whole split is
>  superficial and most java developers are used to get full jvm if they
>  require java.  This would probably change with Java 8 introducing Profiles
>  [1]. And any proper packaging should be modeled after this one. Inventing
>  even more new names/provided/etc. now would just increase the mess we
>  already have.  I remember seeing servlets using awt/ImageIO for image
>  processing on tomcat version running on headless server - and it was
>  leading just to jvm crash. That was in Java 5 times but illustrates the
>  problem. This was easily fixable by adding -Djava.awt.headless=true to
>  Tomcat startup scripts, what I want to point with that is that simply
>  moving a package require java-headless from full java has to be carefully
>  thought on per package base with some changes done to the packages if
>  needed to ensure no such bad examples start to pop out. Java means full
>  JVM so we would better not confuse this with any java-x11(what about
>  wayland coming?) or similar naming at least for now. Also headless(through
>  the java.awt.headless option) is known and well recognized option in Java
>  community while x11 would mean nothing to many Java developers. This keeps
>  us closer to common terms and not deviate needlessly.
>   
And nothing changes the term "java" 's meaning for developers or
users...
The several proposals only add the new term, java-x11 for packagers and
even there, they allow for deprecation, they do not break backwards compat.
Third parties can continue to use Requires: java.  Unaudited code in Fedora
will continue to use Requires: java.  Only when someone has spent the time
to check whether a package will work with headless and determined that it
will not will the package change its Require: to java-x11 (or similar) to
record for future maintainers and other interested parties that the package
cannot be used without the full jvm.

-Toshio

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Toshio Kuratomi" <a.badger(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Wednesday, November 20, 2013 7:53:15 PM
>  Subject: Re: F21 System Wide Change: Headless Java
>  
>  On Wed, Nov 20, 2013 at 12:27:38PM -0500, Aleksandar Kurtakov wrote:
>  > I start to think this conversation goes nowhere. The whole split is
>  > superficial and most java developers are used to get full jvm if they
>  > require java.  This would probably change with Java 8 introducing Profiles
>  > [1]. And any proper packaging should be modeled after this one. Inventing
>  > even more new names/provided/etc. now would just increase the mess we
>  > already have.  I remember seeing servlets using awt/ImageIO for image
>  > processing on tomcat version running on headless server - and it was
>  > leading just to jvm crash. That was in Java 5 times but illustrates the
>  > problem. This was easily fixable by adding -Djava.awt.headless=true to
>  > Tomcat startup scripts, what I want to point with that is that simply
>  > moving a package require java-headless from full java has to be carefully
>  > thought on per package base with some changes done to the packages if
>  > needed to ensure no such bad examples start to pop out. Java means full
>  > JVM so we would better not confuse this with any java-x11(what about
>  > wayland coming?) or similar naming at least for now. Also headless(through
>  > the java.awt.headless option) is known and well recognized option in Java
>  > community while x11 would mean nothing to many Java developers. This keeps
>  > us closer to common terms and not deviate needlessly.
>  > 
>  And nothing changes the term "java" 's meaning for developers or users...
>  The several proposals only add the new term, java-x11 for packagers and
>  even there, they allow for deprecation, they do not break backwards compat.
>  Third parties can continue to use Requires: java.  Unaudited code in Fedora
>  will continue to use Requires: java.  Only when someone has spent the time
>  to check whether a package will work with headless and determined that it
>  will not will the package change its Require: to java-x11 (or similar) to
>  record for future maintainers and other interested parties that the package
>  cannot be used without the full jvm. 
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. I for one would not introduce requires to some virtual provide
that would break compatibility with other JVMs in my packages even after auditing it. And
we end up with one more unused virtual provide on top of all the other which were added
with such good intentions and end up just clutter the situation. If you look at openjdk
spec you'll see provides like - jre, java-fonts, jndi, java-sasl and so on and they
are simply not used. 
They were introduced for various reasons but their usage is the same today - none.
Let's not make the same mistake one more time.

Alexander Kurtakov
Red Hat Eclipse team

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

[Toshio Kuratomi]

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?

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.

-Toshio

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Toshio Kuratomi" <a.badger(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Stanislav Ochotnicky]

Quoting Toshio Kuratomi (2013-11-20 22:46:32)
>  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.
>  
>  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. 
As Alex said, nobody is going to audit 800 packages if maintainers don't care
enough to verify. In theory your "let's audit 800 packages" is good idea.
In
practice it's not going to happen because we have to pick our battles. If you
want to pick this battle then I ask you to commit to providing 2 weeks+ of your
time to auditing (or whatever time you'll need to audit 100 packages). Do a few
java package reviews first to "get in the zone"[1].

I can easily create a cron job that would run once a week and report any
non-whitelisted package that has "Requires: java" to java-devel@. We use
something similar for duplicate provides. But even that is mostly unneeded
because whatever new packages are added they will most likely be leaf packages
or create their own branch (so they won't affect rest of the ecosystem). Plus
the package review should certainly stop those packaging from getting in in the
first place (or have a comment in the spec file why it's needed - if it's not
obvious)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=FE-JAVASIG

-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[Miloslav Trmač]

On Wed, Nov 20, 2013 at 10:46 PM, Toshio Kuratomi <a.badger(a)gmail.com&gt; wrote:
>  In fedora we do our best to figure out what the best course of action
> is and
>  then we execute that. 
"The best course of action" _given some limited
resources_, which may
drastically alter the outcome.

>  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. 
Spec files are a really horrible work tracking system, and in this
case we _shouldn't have any work to track_ anyway.

If the goal is to do something worthwhile for a subset of packages
that someone cares about, we don't need tracking.

If the goal is to actually solve the problem in "the best course of
action" (to use your words), _software_ should be determining which
one of the two dependencies is required, and inserting it.  Not
people.  Not tracked in spec files.  Not tracked in bugzilla.  Not
ever appearing as an item in a package review.  Make it an one-time
project, write tests for the software that manages the dependencies,
forget about it forever.[1]

(IIRC somewhere in the thread it's been suggested that software can't
know which one to use: how would the maintainers know then?)
    Mirek

[1] This glosses over how would one transition from spec files with a
manual Requires: to a Requires: managed by a tool; however the same
principles should ideally apply here as well.

[Jerry James]

On Thu, Nov 21, 2013 at 5:33 AM, Miloslav Trmač <mitr(a)volny.cz&gt; wrote:
>  (IIRC somewhere in the thread it's been suggested that software
> can't
>  know which one to use: how would the maintainers know then?) 
Yes, I raised that question early on in this thread.  The response I
got was to read this:

http://www.oracle.com/technetwork/articles/javase/headless-136834.html

which is a 7 year old article about setting up a headless system with
Java 6, and doesn't mention audio anywhere.  I am willing to do the
work to figure out which of my packages need full java and which can
get by with java-headless, but I need a very clear set of criteria to
work from.  I don't think this article qualifies, nor have I yet seen
such a clear set of criteria.

And Mirek's question bears repeating: if software can't figure this
out reliably, how do you expect us fallible humans to do so?
Apparently it is not as easy as "if your software uses these packages
and/or classes, it needs full java, otherwise java-headless is
enough".  Why not?  What else could cause a dependency on full java?
-- 
Jerry James
http://www.jamezone.org/

[Stanislav Ochotnicky]

Quoting Jerry James (2013-11-21 17:01:07)
>  On Thu, Nov 21, 2013 at 5:33 AM, Miloslav Trmač <mitr(a)volny.cz&gt;
> wrote:
>  > (IIRC somewhere in the thread it's been suggested that software can't
>  > know which one to use: how would the maintainers know then?)
>  
>  Yes, I raised that question early on in this thread.  The response I
>  got was to read this:
>  
>  http://www.oracle.com/technetwork/articles/javase/headless-136834.html
>  
>  which is a 7 year old article about setting up a headless system with
>  Java 6, and doesn't mention audio anywhere.  I am willing to do the
>  work to figure out which of my packages need full java and which can
>  get by with java-headless, but I need a very clear set of criteria to
>  work from.  I don't think this article qualifies, nor have I yet seen
>  such a clear set of criteria. 
I linked to that article because it's relevant. If you read it you know that:
    * java.awt. classes are a problem for headless (except Canvas, Panel and
      Image as mentioned in the article)

Other than that a simple grep for one of following will give you a smoking gun:
    * import javax.sound.

But if you want a simpler guide:
    * Install your app with headless Java
    * Run it
    * Did it crash?
        - No? - good! you can probably use headless
        - Yes? - not good! use full Java VM
    * Did you get any backtraces when running the app that are not normally
      there?
        - No? - good! you can use headless
        - Yes? - not good! use full Java VM

For obvious reasons this is not something we'll be turning into a separate
project. Autorequires/provides don't work on source code but bytecode.

>  And Mirek's question bears repeating: if software can't
> figure this
>  out reliably, how do you expect us fallible humans to do so? 
Software can't reliably detect licenses in packages, yet we routinely do license
review manually as part of Package Review process. It's really not that uncommon
for people to be better than computers at fuzzy tasks.

Call me silly but I expect maintainers to know what their packages actually do.
Seriously though if you really can't figure it out, just ask on java-devel@ (or
#fedora-java on freenode). You can't have more than a handful of Java packages.

>  Apparently it is not as easy as "if your software uses these
> packages
>  and/or classes, it needs full java, otherwise java-headless is
>  enough".  Why not?  What else could cause a dependency on full java? 
It is as easy as "if your software uses these packages and/or classes" but
it's
almost impossible to say if your software uses them due to nature of Java/JVM
itself. There's too many ways to use parts of JVM. Interfaces, intermediate
libraries, various classloading tricks.

Nobody is going to write a reliable detection if it should be headless requires
or not. Much less integrate it into all different Java build systems so that it
actually makes sense to spend time on. 


-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[Miloslav Trmač]

On Thu, Nov 21, 2013 at 8:46 PM, Stanislav Ochotnicky
<sochotnicky(a)redhat.com&gt; wrote:
>  Quoting Jerry James (2013-11-21 17:01:07)
> > On Thu, Nov 21, 2013 at 5:33 AM, Miloslav Trmač <mitr(a)volny.cz&gt; wrote:
> > > (IIRC somewhere in the thread it's been suggested that software can't
> > > know which one to use: how would the maintainers know then?)
> >
> > Yes, I raised that question early on in this thread.  The response I
> > got was to read this:
> >
> > http://www.oracle.com/technetwork/articles/javase/headless-136834.html
> >
> > which is a 7 year old article about setting up a headless system with
> > Java 6, and doesn't mention audio anywhere.  I am willing to do the
> > work to figure out which of my packages need full java and which can
> > get by with java-headless, but I need a very clear set of criteria to
> > work from.  I don't think this article qualifies, nor have I yet seen
> > such a clear set of criteria.
>
>  I linked to that article because it's relevant. If you read it you know that:
>      * java.awt. classes are a problem for headless (except Canvas, Panel and
>        Image as mentioned in the article)
>
>  Other than that a simple grep for one of following will give you a smoking gun:
>      * import javax.sound.
>
>  But if you want a simpler guide:
>      * Install your app with headless Java
>      * Run it
>      * Did it crash? 
These two steps make it rather non-"simple"; one
would also determine
which parts of the code base have not been exercised.


> > And Mirek's question bears repeating: if software can't
> figure this
> > out reliably, how do you expect us fallible humans to do so?
>
>  Software can't reliably detect licenses in packages, yet we routinely do license
>  review manually as part of Package Review process. It's really not that uncommon
>  for people to be better than computers at fuzzy tasks. 
This is not really that kind
of a fuzzy question, and getting licenses
wrong has a potentially much higher cost.

>  Call me silly but I expect maintainers to know what their packages
> actually do. 
Call me silly but I expect computers to do routine tasks, not people.
(... under the assumption that somebody really wants to do a
comprehensive conversion and get this applied to all future Java
packages; I understand that this may not actually be what $you really
want to achieve and spend time on.)

> > Apparently it is not as easy as "if your software uses these
> packages
> > and/or classes, it needs full java, otherwise java-headless is
> > enough".  Why not?  What else could cause a dependency on full java?
>
>  It is as easy as "if your software uses these packages and/or classes" but
> it's
>  almost impossible to say if your software uses them due to nature of Java/JVM
>  itself. There's too many ways to use parts of JVM. Interfaces, intermediate
>  libraries, various classloading tricks. 
Intermediate libraries would carry the
non-headless dependency
themselves, so their users wouldn't have to, would they?

>  Nobody is going to write a reliable detection if it should be
> headless requires
>  or not. 
I suppose this will show how hopelessly naive I am, but wouldn't
"byte
code refers to any class from $list or contains a string constant that
starts with any class name from $list" be sufficently accurate?  Not
provably correct, certainly, but if it got us from 30 unknown false
positives to 1-2 unknown false positives _and_ eliminated a manual
packaging/review step...
     Mirek

[Stanislav Ochotnicky]

Quoting Miloslav Trmač (2013-11-21 20:57:38)
>  > But if you want a simpler guide:
>  >     * Install your app with headless Java
>  >     * Run it
>  >     * Did it crash?
>  These two steps make it rather non-"simple"; one would also determine
>  which parts of the code base have not been exercised. 
The crash will be noticeable in the same way that unsetting DISPLAY variable is
for any other GUI app.

Maybe there's a console app that creates X window only in some cases (batik
comes to mind as a possible candidate here). But that's not normal modus
operandi even in Java world.

>  >> And Mirek's question bears repeating: if software
> can't figure this
>  >> out reliably, how do you expect us fallible humans to do so?
>  >
>  > Software can't reliably detect licenses in packages, yet we routinely do
> license
>  > review manually as part of Package Review process. It's really not that
> uncommon
>  > for people to be better than computers at fuzzy tasks.
>  This is not really that kind of a fuzzy question, and getting licenses
>  wrong has a potentially much higher cost.
>  
>  > Call me silly but I expect maintainers to know what their packages actually do.
>  Call me silly but I expect computers to do routine tasks, not people.
>  (... under the assumption that somebody really wants to do a
>  comprehensive conversion and get this applied to all future Java
>  packages; I understand that this may not actually be what $you really
>  want to achieve and spend time on.) 
As if I spent 3 years making Java packaging more manual...

>  >> Apparently it is not as easy as "if your software uses
> these packages
>  >> and/or classes, it needs full java, otherwise java-headless is
>  >> enough".  Why not?  What else could cause a dependency on full java?
>  >
>  > It is as easy as "if your software uses these packages and/or classes" but
> it's
>  > almost impossible to say if your software uses them due to nature of Java/JVM
>  > itself. There's too many ways to use parts of JVM. Interfaces, intermediate
>  > libraries, various classloading tricks.
>  Intermediate libraries would carry the non-headless dependency
>  themselves, so their users wouldn't have to, would they? 
In most cases, but I can imagine cases where a genric toolkit library with
support for multiple backends didn't want to force-pull full java for a specific
use case.

>  > Nobody is going to write a reliable detection if it should be
> headless requires
>  > or not.
>  I suppose this will show how hopelessly naive I am, but wouldn't "byte
>  code refers to any class from $list or contains a string constant that
>  starts with any class name from $list" be sufficently accurate?  Not
>  provably correct, certainly, but if it got us from 30 unknown false
>  positives to 1-2 unknown false positives _and_ eliminated a manual
>  packaging/review step... 
I don't even dare guess how many false positives you'd get by doing that. Oh and
let's see how fast we can make this. Otherwise autorequires generator is going to
waste a lot of developer time in by doing bytecode analysis on each single class
file.

Regardless..what I meant to say: Nobody - as in I don't see anyone jumping up
and down and volunteering to do the work and maintain the code, provide ways to
workaround those inevitable false positives etc. I have asked and received a
clear "no" from people who actually work on OpenJDK codebase. If anybody things
they are smarted go ahead: prove them wrong

-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[Reindl Harald]

Am 21.11.2013 21:50, schrieb Stanislav Ochotnicky:
>  Regardless..what I meant to say: Nobody - as in I don't see
> anyone jumping up
>  and down and volunteering to do the work and maintain the code, provide ways to
>  workaround those inevitable false positives etc. I have asked and received a
>  clear "no" from people who actually work on OpenJDK codebase. If anybody
> things
>  they are smarted go ahead: prove them wrong 
and that is why metapackge "java" pulling "openjdk" and
"openjdk-headless"
woulkd be the right way because *nobody* would need volunteering because
nothing changes until a single package which may be the only one on
a server changes to "openjdk-headless" instead the full java

that would not be a big win in the first step, but a cheap one

but it can be a big win in case you have 20 servers using whatever java-package
which does not really need the X11 parts and is the only one pulling the
X11 dependency tree, it would require only a single RFE for that package

anybody else out there would see any imapct in any direction

why is it that hard to go *small* and *pragmatic* steps instead always
try to change the world at once?

P.S:
that said from one not using any single java-package any longer on
servers but carried the openjdk for qenta-qtill payment over years
with *a lot* of useless dependencies called by a webserver with surely
no X11 dependency

[Florian Weimer]

On 11/21/2013 08:57 PM, Miloslav Trmač wrote:

>  These two steps make it rather non-"simple"; one would also
> determine
>  which parts of the code base have not been exercised. 
If the test suite is so weak that it doesn't cover such basic issues, 
you will have trouble with *any* change, not just this one.

-- 
Florian Weimer / Red Hat Product Security Team

[Marcela Mašláňová]

On 20/11/13 18:53, Toshio Kuratomi wrote:
>  On Wed, Nov 20, 2013 at 12:27:38PM -0500, Aleksandar Kurtakov wrote:
> > I start to think this conversation goes nowhere. The whole split is
> > superficial and most java developers are used to get full jvm if they
> > require java.  This would probably change with Java 8 introducing Profiles
> > [1]. And any proper packaging should be modeled after this one. Inventing
> > even more new names/provided/etc. now would just increase the mess we
> > already have.  I remember seeing servlets using awt/ImageIO for image
> > processing on tomcat version running on headless server - and it was
> > leading just to jvm crash. That was in Java 5 times but illustrates the
> > problem. This was easily fixable by adding -Djava.awt.headless=true to
> > Tomcat startup scripts, what I want to point with that is that simply
> > moving a package require java-headless from full java has to be carefully
> > thought on per package base with some changes done to the packages if
> > needed to ensure no such bad examples start to pop out. Java means full
> > JVM so we would better not confuse this with any java-x11(what about
> > wayland coming?) or similar naming at least for now. Also headless(through
> > the java.awt.headless option) is known and well recognized option in Java
> > community while x11 would mean nothing to many Java developers. This keeps
> > us closer to common terms and not deviate needlessly.
> >
>  And nothing changes the term "java" 's meaning for developers or users...
>  The several proposals only add the new term, java-x11 for packagers and
>  even there, they allow for deprecation, they do not break backwards compat.
>  Third parties can continue to use Requires: java.  Unaudited code in Fedora
>  will continue to use Requires: java.  Only when someone has spent the time
>  to check whether a package will work with headless and determined that it
>  will not will the package change its Require: to java-x11 (or similar) to
>  record for future maintainers and other interested parties that the package
>  cannot be used without the full jvm.
>
>  -Toshio
>
>
>  
I must agree with Aleksandar, this discussion is going nowhere. There 
weren't mentioned any valid arguments, why to do Wide Change differently 
than proposed by the Change owner.

We were speaking about giving more power to SIGs related to discussion 
about Fedora.next. This can be a good start. Stano and Aleksandar are 
working on Java maintenance a lot, Java SIG members are speaking 
together, so I have a confidence in their actions.

Marcela

[Toshio Kuratomi]

On Wed, Nov 20, 2013 at 08:13:02PM +0100, Marcela Mašláňová wrote:
>  
>  We were speaking about giving more power to SIGs related to
>  discussion about Fedora.next. This can be a good start. Stano and
>  Aleksandar are working on Java maintenance a lot, Java SIG members
>  are speaking together, so I have a confidence in their actions.
>   
This is a tangent but -- some people have been talking about giving more
power to SIGs but at the last env and stacks meeting we sorta settled on
more power to SIGs in an experimental, anything-goes repo.  We're not
tlaking about that here.

-Toshio

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Toshio Kuratomi" <a.badger(a)gmail.com&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Wednesday, November 20, 2013 9:23:29 PM
>  Subject: Re: F21 System Wide Change: Headless Java
>  
>  On Wed, Nov 20, 2013 at 08:13:02PM +0100, Marcela Mašláňová wrote:
>  > 
>  > We were speaking about giving more power to SIGs related to
>  > discussion about Fedora.next. This can be a good start. Stano and
>  > Aleksandar are working on Java maintenance a lot, Java SIG members
>  > are speaking together, so I have a confidence in their actions.
>  > 
>  This is a tangent but -- some people have been talking about giving more
>  power to SIGs but at the last env and stacks meeting we sorta settled on
>  more power to SIGs in an experimental, anything-goes repo.  We're not
>  tlaking about that here. 
I have no idea what was discussed at these meetings but the thing is if such thing would
happen it would only happen if we do it - history has proved that changes don't happen
magically by themself. If one is forced to do something he doesn't think is the
correct he would not do it and if the Java SIG doesn't step in to drive this change we
all lose. While something might sound as the better engineered solution it doesn't
matter if it "burns bridges" to other communities and I do care for e.g. Mageia
developers as they do better than our mass-rebuilds as problems they find often come back
to us even with a patch. 
Not to mention that simply concentrating on what I would call a "temporary
solution" is a mistake too and as such should be done with minimal changes.
Modularizing and naming will come from the OpenJDK upstream in Java 8 to some
extend(Compact Profiles). If such a thing happens to be such a problem and lose time
discussing things that are proved to not work who would even dare to try pushing them into
Fedora. If upstream OpenJDK has a "headless" mode - inventing new name will
break the stay close to upstream, if well established project like Debian calls the same
thing "headless" - we reduce chances to share and collaboration as we end up
people explaining what does x11 and what does headless mean in conversation, if this is a
subject of a change soon - why not let current maintainers do it as they want and get
involved into helping get the profiles. For me this is implementation detail, which gives
nothing but bad feeling into current maintainers as people involved into the actual work
already agreed on the solution - not perfect but the most acceptable one.

Alexander Kurtakov
Red Hat Eclipse team

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

[Reindl Harald]

Am 20.11.2013 20:56, schrieb Aleksandar Kurtakov:
>  ----- Original Message -----
> > From: "Toshio Kuratomi" <a.badger(a)gmail.com&gt;
> > To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
> > Sent: Wednesday, November 20, 2013 9:23:29 PM
> > Subject: Re: F21 System Wide Change: Headless Java
> >
> > On Wed, Nov 20, 2013 at 08:13:02PM +0100, Marcela Mašláňová wrote:
> >>
> >> We were speaking about giving more power to SIGs related to
> >> discussion about Fedora.next. This can be a good start. Stano and
> >> Aleksandar are working on Java maintenance a lot, Java SIG members
> >> are speaking together, so I have a confidence in their actions.
> >>
> > This is a tangent but -- some people have been talking about giving more
> > power to SIGs but at the last env and stacks meeting we sorta settled on
> > more power to SIGs in an experimental, anything-goes repo.  We're not
> > tlaking about that here.
>  
>  I have no idea what was discussed at these meetings but the thing is if 
>  such thing would happen it would only happen if we do it - history has 
>  proved that changes don't happen magically by themself. If one is forced 
>  to do something he doesn't think is the correct he would not do it and 
>  if the Java SIG doesn't step in to drive this change we all lose 
why does everyting in Fedora feels that complicated and needs "big features"
hence throw the "feature" in the basket, split java in 3 packages

* java
* java-headless
* java-x11

and you are done without waste anybodys time, *nobody* will lose and
sooner or later packages which are running headless on servers may or
may not be changed to depend only on "java-headless"

for me sometimes it feels like people forcing big features and changes
involving a lot of people to get more noticed and important instead
think about how can things be optimized with no feelable impact and
demanding anybody to take actions

[Aleksandar Kurtakov]

----- Original Message -----
>  From: "Reindl Harald" <h.reindl(a)thelounge.net&gt;
>  To: devel(a)lists.fedoraproject.org
>  Sent: Thursday, November 21, 2013 11:34:08 AM
>  Subject: Re: F21 System Wide Change: Headless Java
>  
>  
>  Am 20.11.2013 20:56, schrieb Aleksandar Kurtakov:
>  > ----- Original Message -----
>  >> From: "Toshio Kuratomi" <a.badger(a)gmail.com&gt;
>  >> To: "Development discussions related to Fedora"
>  >> <devel(a)lists.fedoraproject.org&gt;
>  >> Sent: Wednesday, November 20, 2013 9:23:29 PM
>  >> Subject: Re: F21 System Wide Change: Headless Java
>  >>
>  >> On Wed, Nov 20, 2013 at 08:13:02PM +0100, Marcela Mašláňová wrote:
>  >>>
>  >>> We were speaking about giving more power to SIGs related to
>  >>> discussion about Fedora.next. This can be a good start. Stano and
>  >>> Aleksandar are working on Java maintenance a lot, Java SIG members
>  >>> are speaking together, so I have a confidence in their actions.
>  >>>
>  >> This is a tangent but -- some people have been talking about giving more
>  >> power to SIGs but at the last env and stacks meeting we sorta settled on
>  >> more power to SIGs in an experimental, anything-goes repo.  We're not
>  >> tlaking about that here.
>  > 
>  > I have no idea what was discussed at these meetings but the thing is if
>  > such thing would happen it would only happen if we do it - history has
>  > proved that changes don't happen magically by themself. If one is forced
>  > to do something he doesn't think is the correct he would not do it and
>  > if the Java SIG doesn't step in to drive this change we all lose
>  
>  why does everyting in Fedora feels that complicated and needs "big features"
>  hence throw the "feature" in the basket, split java in 3 packages
>  
>  * java
>  * java-headless
>  * java-x11
>  
>  and you are done without waste anybodys time, *nobody* will lose and
>  sooner or later packages which are running headless on servers may or
>  may not be changed to depend only on "java-headless"
>  
>  for me sometimes it feels like people forcing big features and changes
>  involving a lot of people to get more noticed and important instead
>  think about how can things be optimized with no feelable impact and
>  demanding anybody to take actions 
I agree with you that the current Features/Changes system is useless as is now. It was
supposed to be a way to collect information for Release notes nothing more AFAIK.
Discussions, decisions, changes and so on happen in whatever way the parties doing the
work think is better for them. The idea that changes become a way for enforcing stuff on
maintainers plain means that one would better not care for the process at all and do the
changes needed and not care with the bureaucrasy.

Alexander Kurtakov
Red Hat Eclipse team

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

[Miloslav Trmač]

On Thu, Nov 21, 2013 at 1:31 PM, Aleksandar Kurtakov
<akurtako(a)redhat.com&gt; wrote:
>  I agree with you that the current Features/Changes system is useless
> as is now. It was supposed to be a way to collect information for Release notes nothing
> more AFAIK. 
> From the FESCo side, IMHO "collecting information for Release
> Notes" 
was fairly useless; the current system allows every affected
maintainer to be aware of changes and raise concerns, and this has led
several times to significantly altering the proposal for the better.

>  Discussions, decisions, changes and so on happen in whatever way the
> parties doing the work think is better for them. 
The "parties doing the work" proposed to:
>  (optional) Mass-change spec files that have "Requires:
> java" to "Requires: java-headless" 
I.e. mass-break non-headless
packages, and to ask "Other developers"
to clean up after the Change owners breaking their packages.  That's
may actually be the right thing to do (I'm uncertain), but at the very
least the affected maintainers should have an opportunity to speak up
whether they are willing to do it or not, and that's the reason the
Change process is imposing a public discussion.

In the thread you and others have suggested that there in fact there
are no or few "Other developers", and this is all a Java SIG internal
thing; I don't know whether it's true (and I don't currently care to
collect the data); the proposal certainly hasn't been written that
way.
     Mirek

[Stanislav Ochotnicky]

Quoting Miloslav Trmač (2013-11-21 13:48:51)
>  On Thu, Nov 21, 2013 at 1:31 PM, Aleksandar Kurtakov
>  <akurtako(a)redhat.com&gt; wrote:
>  > I agree with you that the current Features/Changes system is useless as is now. It
> was supposed to be a way to collect information for Release notes nothing more AFAIK.
>  
>  From the FESCo side, IMHO "collecting information for Release Notes"
>  was fairly useless; the current system allows every affected
>  maintainer to be aware of changes and raise concerns, and this has led
>  several times to significantly altering the proposal for the better.
>  
>  > Discussions, decisions, changes and so on happen in whatever way the parties doing
> the work think is better for them.
>  
>  The "parties doing the work" proposed to:
>  > (optional) Mass-change spec files that have "Requires: java" to
> "Requires: java-headless"
>  I.e. mass-break non-headless packages, and to ask "Other developers"
>  to clean up after the Change owners breaking their packages.  That's
>  may actually be the right thing to do (I'm uncertain), but at the very
>  least the affected maintainers should have an opportunity to speak up
>  whether they are willing to do it or not, and that's the reason the
>  Change process is imposing a public discussion.
>  
>  In the thread you and others have suggested that there in fact there
>  are no or few "Other developers", and this is all a Java SIG internal
>  thing; I don't know whether it's true (and I don't currently care to
>  collect the data); the proposal certainly hasn't been written that
>  way. 
From my perspective as Change owner, I proposed it for two reasons:
    * Release notes and just wider audience for the change (as Alex mentioned)
    * Get feedback on *serious* problems with the proposal

I agree that *affected maintainers* should have an opportunity to speak up.
Based on their input in the thread I believe noone objected to mass filing bug,
waiting a bit for maintainers to either look themselves or fix it up
automatically.  *That* kind of input was constructive and helped flesh out the
process for rolling out the change for users/maintainers. 


-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[Stanislav Ochotnicky]

Quoting Miloslav Trmač (2013-11-21 13:48:51)
>  In the thread you and others have suggested that there in fact there
>  are no or few "Other developers", and this is all a Java SIG internal
>  thing; I don't know whether it's true (and I don't currently care to
>  collect the data); the proposal certainly hasn't been written that
>  way. 
For your enjoyment, top 20 java package owners:
    145  gil
     67  goldmann
     44  mbooth
     38  sochotni
     36  msrb
     30  mizdebsk
     21  jhernand
     19  jcapik
     19  galileo
     17  orion
     16  spike
     16  omajid
     16  huwang
     14  caolanm
     13  mmorsi
     13  madsa
     11  akurtakov
      9  ricardo
      8  fnasser
      7  pahuang


Funnily enough none of these people complain about current change proposal. And
these people own ~550 packages out of those 800.

-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[Marcela Mašláňová]

On 20/11/13 20:23, Toshio Kuratomi wrote:
>  On Wed, Nov 20, 2013 at 08:13:02PM +0100, Marcela Mašláňová wrote:
> >
> > We were speaking about giving more power to SIGs related to
> > discussion about Fedora.next. This can be a good start. Stano and
> > Aleksandar are working on Java maintenance a lot, Java SIG members
> > are speaking together, so I have a confidence in their actions.
> >
>  This is a tangent but -- some people have been talking about giving more
>  power to SIGs but at the last env and stacks meeting we sorta settled on
>  more power to SIGs in an experimental, anything-goes repo.  We're not
>  tlaking about that here.
>
>  -Toshio
>
>
>  
For now. I would be for more power to SIGs, because who does the work 
has the responsibility. I don't think people outside Java word can 
decide how it should be done.

I still don't see any reason, why should be Change proposal done 
differently. Could you sum it up in few points?
Marcela

[Toshio Kuratomi]

On Thu, Nov 21, 2013 at 11:06:44AM +0100, Marcela Mašláňová wrote:
>  On 20/11/13 20:23, Toshio Kuratomi wrote:
>  >On Wed, Nov 20, 2013 at 08:13:02PM +0100, Marcela Mašláňová wrote:
>  >>
>  >>We were speaking about giving more power to SIGs related to
>  >>discussion about Fedora.next. This can be a good start. Stano and
>  >>Aleksandar are working on Java maintenance a lot, Java SIG members
>  >>are speaking together, so I have a confidence in their actions.
>  >>
>  >This is a tangent but -- some people have been talking about giving more
>  >power to SIGs but at the last env and stacks meeting we sorta settled on
>  >more power to SIGs in an experimental, anything-goes repo.  We're not
>  >tlaking about that here.
>  >
>  >-Toshio
>  >
>  >
>  >
>  For now. I would be for more power to SIGs, because who does the work
>  has the responsibility. I don't think people outside Java word can
>  decide how it should be done.
>   
If we're talking about the same powers (I'm talking about Packaging 
Guideline
approval) then I would be against giving that to SIGs for the same reasons
I gave in the Env and Stacks Meeting. Importance of precedence, importance
of big picture view of how it fits into Fedora and its policies.  SIGs come
up with what's expedient for them to package but that's not always the thing
that is going to make it easy for other packagers to get involved, end users
to use their packages, or advance Fedora's goals.

>  I still don't see any reason, why should be Change proposal done
>  differently. Could you sum it up in few points? 
Not here, I'll continue to do that in the other part of the thread to not
get this tangent involved in it :-)

-Toshio

[Miloslav Trmač]

On Wed, Nov 20, 2013 at 8:13 PM, Marcela Mašláňová <mmaslano(a)redhat.com&gt; wrote:
>  On 20/11/13 18:53, Toshio Kuratomi wrote:
> > On Wed, Nov 20, 2013 at 12:27:38PM -0500, Aleksandar Kurtakov wrote:
> >>
> >> I start to think this conversation goes nowhere. The whole split is
> >> superficial and most java developers are used to get full jvm if they
> >> require java.  This would probably change with Java 8 introducing
> >> Profiles [1]. 
(Then I suppose the real question is whether we should be doing this
now at all... but under the model that most packages don't actually
need to be touched for the few people who care to benefit, I can't see
a reason to say no.)


>  We were speaking about giving more power to SIGs related to
> discussion about
>  Fedora.next. This can be a good start. Stano and Aleksandar are working on
>  Java maintenance a lot, Java SIG members are speaking together, so I have a
>  confidence in their actions. 
That's not really what Fedora.next is about AFAICT, and separately
from that not all that reasonable either; upstream language
communities have their different ways of doing things and the language
SIGs are constantly at risk of isolating themselves and their
practices from the rest of the distribution.

In fact I'd (as a purely personal opinion) very prefer the Env/Stacks
WG to set up _cross-language_ mechanisms for language and middleware
runtimes, that are administered, packaged and behave substantially
equally for all of them.
     Mirek

[Miloslav Trmač]

On Fri, Nov 15, 2013 at 12:28 PM, Jaroslav Reznik <jreznik(a)redhat.com&gt; 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?
     Mirek

[Richard W.M. Jones]

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(a)redhat.com&gt; 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.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

[Nicolas Mailhot]

Le Sam 16 novembre 2013 10:13, Richard W.M. Jones a écrit :

>  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) 
I'm pretty sure that depends on the jvm modularization work which has been
repeatedly delayed upstream

Regards,

-- 
Nicolas Mailhot

[Jon VanAlten]

----- Original Message -----
>  From: "Nicolas Mailhot"
> <nicolas.mailhot(a)laposte.net&gt;
>  To: "Development discussions related to Fedora"
> <devel(a)lists.fedoraproject.org&gt;
>  Sent: Saturday, November 16, 2013 2:51:08 AM
>  Subject: Re: F21 System Wide Change: Headless Java
>  
>  
>  Le Sam 16 novembre 2013 10:13, Richard W.M. Jones a écrit :
>  
>  > 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)
>  
>  I'm pretty sure that depends on the jvm modularization work which has been
>  repeatedly delayed upstream
>   
Well, in theory it would be possible to implement automated provides
and requires w/o jdk modularization, but likely there would be a lot
of effort that would go out the window once we do have a modular jdk.
Also, any future auto provides/requires are much more likely to be at
the module level, not the class level, as this is how tooling for a
modularized java will be geared.  Not to mention the issue Stanislav
mentioned with 100s or 1000s of provides and requires generated in a
typical package.  I actually had a prototype patched rpmbuild with
auto module requires/provides working some time ago when Jigsaw was
still targeted for JDK7 (I think that was still Sun, to give you an
idea how long ago), which is also long before upstream decided to
toss the existing Jigsaw impl and start again :/  I learned my lesson,
and won't spend more time until upstream has actually merged
modularization work to a release branch.

cheers,
jon

[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(a)redhat.com&gt; 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(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[Tomas Mraz]

On Po, 2013-11-18 at 07:20 +0100, Stanislav Ochotnicky wrote:

>  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. 
That is no reason for breaking these 30 broken packages without at least
giving the package maintainer a chance to opt out of getting it broken.

>  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 
I could agree with this plan.

>  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. 
Don't be so pessimistic - if you eliminate 95% of unneeded full Java
dependencies, taking away the rest 5% on case by case basis would not be
impossible even manually. Why it would be so catastrophic that some
obscure server package would pull full Java? I mean it should not be
hard for server admins to spot such package and report a bug for it
appropriately.

And I don't really believe package maintainers will blindly close the
bugs if their package requires only headless Java. I much more believe
the maintainers will ignore the bug even if the package requires full
Java which will mean that the package gets broken after the mass change.
But that's a maintainer ignorance problem then and not just mass
breaking packages by a script.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)

[Kevin Fenzi]

On Mon, 18 Nov 2013 07:20:34 +0100
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt; wrote:

...snip...

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

If you are going to file a mass of bugs, please see: 
http://fedoraproject.org/wiki/Mass_bug_filing

kevin

[Jerry James]

On Sun, Nov 17, 2013 at 11:20 PM, Stanislav Ochotnicky
<sochotnicky(a)redhat.com&gt; wrote:
>  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. 
Then how are we maintainers supposed to determine if our packages
require full java, or just java-headless?  "Needs X or audio" is too
vague.  Is there a list of packages and/or classes that are present in
full java but not in java-headless?  Or some kind of explicit set of
guidelines I can use to examine my packages to see which they need?
-- 
Jerry James
http://www.jamezone.org/

[Stanislav Ochotnicky]

Quoting Jerry James (2013-11-18 16:54:28)
>  On Sun, Nov 17, 2013 at 11:20 PM, Stanislav Ochotnicky
>  <sochotnicky(a)redhat.com&gt; wrote:
>  > 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.
>  
>  Then how are we maintainers supposed to determine if our packages
>  require full java, or just java-headless?  "Needs X or audio" is too
>  vague.  Is there a list of packages and/or classes that are present in
>  full java but not in java-headless?  Or some kind of explicit set of
>  guidelines I can use to examine my packages to see which they need? 
You can use following Oracle article as a starting point[1]. But maybe OpenJDK
maintainers can provide better alternative. Generally though there are *very*
few packages in Fedora that would require full java. 


[1] http://www.oracle.com/technetwork/articles/javase/headless-136834.html


-- 
Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Developer Experience

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

[Deepak Bhole]

* Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt; [2013-11-19 03:35]:
>  Quoting Jerry James (2013-11-18 16:54:28)
>  > On Sun, Nov 17, 2013 at 11:20 PM, Stanislav Ochotnicky
>  > <sochotnicky(a)redhat.com&gt; wrote:
>  > > 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.
>  > 
>  > Then how are we maintainers supposed to determine if our packages
>  > require full java, or just java-headless?  "Needs X or audio" is too
>  > vague.  Is there a list of packages and/or classes that are present in
>  > full java but not in java-headless?  Or some kind of explicit set of
>  > guidelines I can use to examine my packages to see which they need?
>  
>  You can use following Oracle article as a starting point[1]. But maybe OpenJDK
>  maintainers can provide better alternative. Generally though there are *very*
>  few packages in Fedora that would require full java. 
>   
Another possible resource is checking the Debian package repo -- they
have had headless/full separated for a while (maybe even from the
start?):

e.g. Azureus needs full: http://packages.debian.org/wheezy/azureus and
ant needs headless: http://packages.debian.org/wheezy/ant

Of course it is no guarantee that Debian is perfect -- if we find any
known issues, we can report back accordingly to help improve their set
up too.

Deepak

>  
>  [1] http://www.oracle.com/technetwork/articles/javase/headless-136834.html
>  
>  
>  -- 
>  Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt;
>  Software Engineer - Developer Experience
>  
>  PGP: 7B087241
>  Red Hat Inc.                               http://cz.redhat.com
>  -- 
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Nicolas Mailhot]

Le Mar 19 novembre 2013 09:35, Stanislav Ochotnicky a écrit :

>  You can use following Oracle article as a starting point[1]. But
> maybe
>  OpenJDK
>  maintainers can provide better alternative. Generally though there are
>  *very*
>  few packages in Fedora that would require full java.
>
>
>  [1] http://www.oracle.com/technetwork/articles/javase/headless-136834.html 
May I point out that when jpackage tried to streamline Java packaging we
unilaterally decided java would mean the JRE (not the full jdk as was
commonly used at the time) and various gui bits suchs as fonts were moved
to separate subpackages

So having the main java package mean 'something minimal sufficient for
most uses, add other subpackages if you need to' is nothing new.

Regards,

-- 
Nicolas Mailhot