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@xxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
