>> That it comes from ubuntu is no excuse. > Actually it sounds to me more like a reason to do it not ;-)
Hi all, on second thought, it is probably exactly because of the gnome3 transition. Somewhere someone got an "Ooops" in some java application because the obsolete gnome2 libraries with their deprecated functions where missing. But instead of doing the second-to-right thing and adding those as dependencies to the application that needs them, the java sdk was infested. (The right thing to do would have been to replace gnome_url_show by gtk_show_uri, but this is in the hands of the glacially moving development process of sun/oracle.) After all the research and web browsing, the only component relevant to this bug discussion remains the awt.Desktop class with the wrongly named XDesktopPeer implementation (should have been GnomeDesktopPeer). nio.fs.GnomeFileTypeDetector should, for thruth in naming, be renamed (along with the comments inside) to nio.fs.GlibFileTypeDetector (or ...Gtk...), since by now both gio and gvfs are glib components. And glib is a basis of gtk+, so it is not a superfluous dependency. For gconf I was not able to locate an occurrence in the available source code. Some mail-list entries hint to java webstart, gnu classpath and icedtea, where the proxy configuration might be read using gconf, but in debian neither icedtea nor classpath (gcj-jre) depend on gconf. Was there ever a bug report that on a non-gnome system javaws missed gconf? Anyway, gconf is deprecated, and no package outside the desktop applications should depend on a desktop settings daemon. ----- To summarize, the gnome bias in linux-openjdk was noticed and filed in several instances as java bug in 2006 following the opensourcing of the java7 project. The libgnome function gnome_url_show was declared deprecated in 2009. Since then all that functionality is handled by gtk+ or one level below by glib-gio. In all these years nothing was done on these topics, probably because close to none ever used this functionality, that is, the desktop open method. (Half of the other desktop methods are unimplemented anyway.) If, by chance, some application, nevertheless, uses the desktop class, then this application should also provide the dependencies to libgnome2. And not the general purpose package openjdk-7-sdk. (Since jre might be replaced with jre-headless, only people that want to compile java applications are burdened with these obsolete dependencies.) ---- Could some of the maintainers please confirm or reject those observations and assumptions? With kind regards, Lutz Lehmann -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
