Hey, > i was not referring to the GNU auto* tools, or GCC. the auto* tools > are mostly scripts (with the exception of libltdl), and they aren't > that hard to upgrade or back out. as far as GCC goes, that's a little > above my pay grade. it would be very arrogant of me to tell Sun what > compiler to include in their distro. so i never dreamt of going there. > :-)
Ahh, ok - but I think we can potentially share a good build environment too. Have a look at the following tarball of the type of build environment we provide for JDS - http://www.gnome.org/~gman/wells-cbe.tar.bz2 Don't mind the wells name - that was just yet another project name for JDS on Solaris. Laca is currently working on making that more generic, and what it will take to get those types of tools into mainstream Solaris. > i was referring to all the libraries on which both GNOME and KDE have > dependencies. for example: libxml2, libxslt, libpng, libz, libjpeg, > etc, etc. Right. > currently, the situation seems to me a little out of control. there > are so many independent distros, each and every one of them with their > own versions of these lib dependencies. which makes for a not so nice > experience for someone installing independent distros of KDE or GNOME, > or something even worse: they end up with 3 or 4 different version of > libxml2 for example, in different places! now, realistically speaking, > how many versions of libxml2 does one really need on a box ? :-) same > goes for most of the other dependency libs. Yes, it's a little insane alright. I think we should be safe and sane with libpng, libjpeg, libz as they are relatively slow moving and their interfaces are pretty stable [although currently marked as 'External' in /usr/sfw]. libxml2 and libxslt might be a little bit more problematic though. I know as a JDS team we're pretty much over the barrel with whatever version of the libraries that GNOME requires - and while Daniel Veillard tries to stand by the ABI and API compatibility, we often require a newer version than the one that's currently shipped with Solaris and often don't have time to request an upgrade. We've had to package our own private copies of libxml2 and libxslt in the past. While libxml2 is marked as 'Standard', libxslt is marked as 'Evolving' so we probably have slightly more leeway with that. > so my idea was: would it be possible to work together and create a > common and consistent foundation for OpenSolaris, for these dependency > libraries, for GNOME/JDS and KDE and anything else ? i fully realize > this is no easy task, and it probably will be very time consuming to > sift through every single one of them, and find a common version which > works with both. but i am thinking that the alternative -- which is > continuing this inconsistent setup for these dependency libraries -- > is worse. the idea being that: we would find the common version for > these libraries which works on both JDS/GNOME and KDE, and that > version would become the "official" version. and consequently, any > upgrades to these libraries would have to maintain the same > compatibility rules. Sounds good to me - just remember it's not *just* GNOME/JDS and KDE that we need to work with. Other projects may or may not have dependencies on libraries like libxml2 and that's where the fun begins ;) > the way i understand it, these dependencies fall in three categories: > > 1. common to JDS/GNOME and KDE (just for demo purposes let's call it > "osde-core") > 2. specific to JDS/GNOME ("osde-jds") > 3. specific to KDE ("osde-kde") Yep - I think we definitely want/need to coordinate with the common dependencies and get a definitive list of what we need. The JDS team currently own SUNWpng, SUNWjpg, SUNWPython, SUNWTiff, SUNWlibpopt so that should make things a little easier ;) > and then a fourth one which is really a subset of (3): KDE has > dependencies on gstreamer, > scrollkeeper and glib/gtk, which are part of JDS/GNOME. as a side > note, my packages are linked against the Sun JDS/GNOME gstreamer, and > the Gimp screenshots are with the Sun JDS Gimp. That's an interesting one - is that a hard dependency? I'm only asking because if you're going to depend on GStreamer, for example, then it'll require installing the SUNWgnome-media package, which has other package dependencies ie. it might not be possible at the moment to distribute KDE without distributing the entire GNOME/JDS stack, which is obviously not very desirable to some ;) > the benefits of this would be: > > - a common, consistent core foundation > - more appeal to the "outside contributor" -- meaning, if OpenSolaris > comes out of the box with these dependencies in a familiar place, it > is much easier for someone coming from the GNU/Linux world to get > accustomed to this new environment: pretty much the familiar things > are there. > - make our lives easier down the road, given the fact that both GNOME > and KDE release quite often Absolutely agree - we really need to make compiling KDE and GNOME applications as easy as possible, and would be great to provide a really good developer environment to achieve this. > as to where exactly these things should go: i don't know if it is my > place to say things like "this should go here and that should go > there". i think this should be part of our conversation, and be a > consensus decision. Well, really we're probably bound by some level of ARC constraints on this - but definitely something to work with. > and now finally (and briefly i promise) what's in /opt/fsw4sun and why > it is there: > > what's in it: everything + the kitchen sink (from libpng to openldap > to libdvdread to xine to samba3 to glut 3.7 to icecast 2.2 which can > stream video to my build of libGLU/libGLw and libOsMesa to PostgreSQL > to GNU su/ls/cp, and so on). all of them built with SunStudio10 (on > IA32) or SunStudio9/SunStudio10 (on SPARC). Neat, there's definitely some bits we'd probably like to use in JDS too! I look forward to working with you. Glynn _______________________________________________ opensolaris-discuss mailing list [email protected]
