Re: F21 System Wide Change: Headless Java
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
Am 20.11.2013 20:56, schrieb Aleksandar Kurtakov: - Original Message - From: Toshio Kuratomi a.bad...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org 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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Thu, Nov 21, 2013 at 1:31 PM, Aleksandar Kurtakov akurt...@redhat.com 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
Quoting Jerry James (2013-11-21 17:01:07) On Thu, Nov 21, 2013 at 5:33 AM, Miloslav Trmač m...@volny.cz 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 sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
Quoting Miloslav Trmač (2013-11-21 13:48:51) On Thu, Nov 21, 2013 at 1:31 PM, Aleksandar Kurtakov akurt...@redhat.com 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 sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Wed, Nov 20, 2013 at 10:46 PM, Toshio Kuratomi a.bad...@gmail.com 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Thu, Nov 21, 2013 at 8:46 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Jerry James (2013-11-21 17:01:07) On Thu, Nov 21, 2013 at 5:33 AM, Miloslav Trmač m...@volny.cz 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Wed, Nov 20, 2013 at 8:13 PM, Marcela Mašláňová mmasl...@redhat.com 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@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.bad...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Thu, Nov 21, 2013 at 5:33 AM, Miloslav Trmač m...@volny.cz 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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 pgpZsoeFjeLrd.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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
Re: F21 System Wide Change: Headless Java
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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
Re: F21 System Wide Change: Headless Java
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.bad...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org 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
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. -Toshio pgpVwa3yQbmYM.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
- Original Message - From: Toshio Kuratomi a.bad...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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. -Toshio pgpbCg7FMFRnW.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
- Original Message - From: Toshio Kuratomi a.bad...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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? 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 pgpRrm1tW2yvK.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
- Original Message - From: Toshio Kuratomi a.bad...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org 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
Re: F21 System Wide Change: Headless Java
Quoting Jerry James (2013-11-18 16:54:28) On Sun, Nov 17, 2013 at 11:20 PM, Stanislav Ochotnicky sochotni...@redhat.com 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 sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 sochotni...@redhat.com 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 pgpY1XGxzp3Tw.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
* Stanislav Ochotnicky sochotni...@redhat.com [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 sochotni...@redhat.com 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 sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 sochotni...@redhat.com 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 sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
-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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 pgplD91lxhEjm.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
Quoting Ville Skyttä (2013-11-15 18:30:33) On Fri, Nov 15, 2013 at 3:22 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: http://pkgs.fedoraproject.org/cgit/jing-trang.git/commit/?id=6d46e64fe0f365a947c7095adaf65e8cc2c90d5b 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 sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Mon, 18 Nov 2013 07:20:34 +0100 Stanislav Ochotnicky sochotni...@redhat.com 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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
- Original Message - From: Nicolas Mailhot nicolas.mail...@laposte.net To: Development discussions related to Fedora devel@lists.fedoraproject.org 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Sun, Nov 17, 2013 at 11:20 PM, Stanislav Ochotnicky sochotni...@redhat.com 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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Nov 15, 2013 4:09 AM, Stanislav Ochotnicky sochotni...@redhat.com 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Sat, Nov 16, 2013 at 02:34:00AM +0100, Miloslav Trmač wrote: On Fri, Nov 15, 2013 at 12:28 PM, Jaroslav Reznik jrez...@redhat.com 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#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
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 Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 sochotni...@redhat.com 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) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Fri, Nov 15, 2013 at 2:09 PM, Stanislav Ochotnicky sochotni...@redhat.com 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=6d46e64fe0f365a947c7095adaf65e8cc2c90d5b -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
Quoting Ville Skyttä (2013-11-15 14:11:37) On Fri, Nov 15, 2013 at 2:09 PM, Stanislav Ochotnicky sochotni...@redhat.com 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=6d46e64fe0f365a947c7095adaf65e8cc2c90d5b 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 sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
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 sochotni...@redhat.com 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=6d46e64fe0f365a947c7095adaf65e8cc2c90d5b 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 attachment: puntogil.vcf-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Fri, Nov 15, 2013 at 3:22 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: http://pkgs.fedoraproject.org/cgit/jing-trang.git/commit/?id=6d46e64fe0f365a947c7095adaf65e8cc2c90d5b 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Fri, Nov 15, 2013 at 12:28 PM, Jaroslav Reznik jrez...@redhat.com 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
