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@xxxxxxxxxx> Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
