James: >> I know that we do not archive the latest "stable" build on the >> OpenSolaris download site. However, I am not sure it would be useful >> to provide this, since the Vermillion releases are closely tied to the >> version of the kernel that we integrate it with. In other words, the >> last stable Vermillion build we integrated into the last OpenSolaris >> release probably would not install cleanly on older SXCE/SXDE builds due >> to changes in imported interfaces. So if you want the latest stable >> release, I would recommend to simply install the last OpenSolaris >> release. >> > Why is it dependent on the kernel? Are you referring to the libc > component of ON?
Sorry, I misspoke. Instead of "kernel" I should have said, "the stack which GNOME depends on". For example, I mean new imported interfaces in the Xserver, new HAL interfaces, updated versions of libraries like libxml/libxslt, printing interfaces, etc. In other words, any component of OpenSolaris which GNOME depends upon, but the GNOME team does not deliver. If these are out-of-sync (e.g. if you install the latest vermillion-devel build on top of an older version of OpenSolaris), then things can break. Sometimes you can get away with installing a new version of vermillion-devel on an older version of OpenSolaris if you are lucky and they haven't changed. However, it obviously is not supported, and your results will vary. > It doesn't sit well with me hearing the way you worded it, this is a > desktop, there is an ABI in libc, there is hardly ever any component > removal in the kernel, so kernels should resolve, and you probably > shouldn't be directly depending on the interfaces anyways. I was not meaning libc at all. It, as you highlight, is very stable. However, there are a lot of libraries in Solaris which are not delivered by the GNOME team, which do change. For example, I had a problem a while back where D-Bus stopped working when I tried to install a new vermillion-devel release on an older Nevada build. The problem turned out to be the fact that the configure script of the newer vermillion-devel build was finding and linking in a new interface which was added to a later version of Nevada than I was using. I was able to work around the problem by simply recompiling D-Bus on my system, so that configure was able to figure out I didn't have that interface. This is just an example of the sorts of problems you can run into when you try to use a newer vermillion-devel on an older Solaris build. If you have enough time and experience, you can often work around such issues, but it would probably be difficult for the novice user to figure this sort of thing out. Brian
