Le mercredi 03 novembre 2010 à 22:28 +0200, Ville Skyttà a Ãcrit : > On Wednesday 03 November 2010, Nicolas Mailhot wrote: > > Le mercredi 03 novembre 2010 à 21:32 +0200, Ville Skyttà a Ãcrit : > > > On Wednesday 03 November 2010, Nicolas Mailhot wrote: > > > > Le mercredi 03 novembre 2010 à 19:27 +0200, Ville Skyttà a Ãcrit : > > > > > 3) In my opinion, the whole alternatives setup in the JRE and SDK > > > > > packages should be purged. It's a relic from times that are long > > > > > gone, > > > > > > > > Having a semi-sane way to install multi-vendor multi-version JVMs is > > > > still needed EPEL side. Expensive apps like SAP still make you install > > > > the specific JVM they've been qualified against. > > > > > > But such JVMs do not need to be made the system default at all, people > > > can just run $expensive_app with it by whatever means they like (e.g. > > > direct modification of $PATH, $JAVA_HOME, etc _for that specific app_). > > > > When you pass a certain level of expensiveness, ISVs just assume the > > *only* jvm on the system will be the one they require (quite simply the > > software price is many times the price of hardware, so there is no > > reason to share the hardware with anything else). > > Ok. So again, for what do you need the alternatives stuff for in this > scenario? You need it to keep the jvm packaging modular and not have to package the same jvm in multiple ways (jvm-as-system-default, jvm-as-secondary-jvm, jvm-a-for-mixing-with-jvm-b, etc). For practical purposes the "Enterprise" market is still stuck where JPackage was when we added alternatives (which, btw, I hate dearly). And it's unreasonable to expect those ISVs to change when Fedora has not managed to package a working JBoss. If the Red Hat Java packaging can not even be used with the top Red Hat Java product, what is there to say? (and on this subject, I don't think Fedora Java can be dissociated from Red Hat java) The main reason other project members went for the packaging changes I proposed in JPackage at the time (what people call the JPackage guidelines now) is that I got the then top floss java application, tomcat, to work with them (which was a beast to do alone before others joined the ship). I find it worrying that Java packaging changes are proposed now, but nobody seems to have taken the time to repackage a big demanding java app with the new guidelines as a reality check. But those who do the work decide, that was true then and is true now, and I'm definitely not doing java packaging anymore. So feel free to ignore me. -- Nicolas Mailhot -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
