F21 System Wide Change: Headless Java

[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 at . 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 at redhat.com>
Software Engineer - Developer Experience

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