This page is an attempt to answer some of the more common, "HUH? Why do you guys do it that way?!?!???" questions.
There may be some questions that are just listed here, but do not have their "answers" written up yet.

Why don't you guys use Sun packages of [...]

The original, waaay-back-when concept of CSW packages that Phil had, was originally to layer on top of sun's "SFW" companion cd packages. This was tried, and unfortunately, fell short. Sun simply does not update some common components often enough, to meet the requirements of a user community that expects to dynamically update their free software with a "pkg-get update all" once a month, or similar. They expect the latest version of SuperApp... which in turn requires the latest version of SubLib, ....

This is actually not a fault of Sun: this is a sensible engineering choice on their part. Most "large enterprise" use of Solaris, is based on the premise that the things in Solaris, are highly stable and thoroughly tested. It takes a certain amount of time to test something thoroughly. That conflicts with the desire for "gimme the latest!!".

So basically, "the latest, or proven stable/mature: pick one".
Sun is in the business of providing "stable/mature" (and we hope they stay that way!)

Additionally.. we support solaris 8. Sun's companion CD, doesnt. We have to compile that stuff anyway. So.. given that we have packaged versions of the software... and it is commonly newer than what sun offers... it makes more sense to depend on "our" packages, rather than Sun's.

Well then how about using Sun's packges when they're up to date?

Sorry, (SVR4) packaging dependancies don't work that way. You can either depend on CSWlibsoft, or SUNWlibsoft, but not both. And besides which, sometimes, there ends up being compiled-in stuff related to whether the libraries live in /opt/csw, or /usr/somewhere. So.... Not A Good Idea, unfortunately.

Why don't you guys have Solaris 10 packages?!!

Well, we do have a few, actually. For those cases where it is completely clear that a solaris-10 specific package is required, to get useful features, we make one available. For the majority of cases, however, there simply is no noticable benefit to compiling on solaris 10, compared to compiling on solaris 8. If you find a case where there is, please let the package maintainer know how to reproduce it, and they will then be then empowered to make a solaris 10 specific package.

When possible, we try to make a "Solaris 8" package, that includes optional Solaris 10+ features as a transparent layer. This is in order to support "large site" installations, that like to NFS share the /opt/csw filesystem out from a central location, read-only. This then makes it possible to have a single central NFS server (or cluster of servers) that can serve out a single, highly redundant NFS filesystem, across multiple releases of Solaris.

Why don't you guys compile for [sparc vUltraPlusSuperDooper?]

Short answer: because it doesnt help that much in most cases. For those cases where it does, we usually provide cpu-optimized libs that automatically get pulled in, through the magic of $ISALIST.

If there is a specific program that gets appreciable benefits from cpu-specific optimizations (greater than 5%), then you are encouraged to contact the maintainer of that package, so that we can work out the best way to support that specific software/cpu combination.