Why do packages go by two names (e.g. CSWftype2 and freetype2)?
There are two names assiocated with every piece of software that we ship: a package name and a catalog name. For the example above CSWftype2 is the package name and freetype2 is the catalog name. The different naming may cause confusion, but as with most things, there is a good reason for it. Understanding the purpose of the dual-naming will help you to cope with it.
Package name
The package name is the Solaris SVR4 package name. It is the name used by the native Solaris package management tools like pkgrm or pkginfo. These names have traditionally included a “company” prefix (CSW in our case) and were originally limited to 9 characters. This leads to sometimes cryptic names as the full software title may be condensed to fit historical limits (freetype2 -> CSWftype2).
Catalog name
The catalog name, on the other hand, doesn’t have these length limitations. This name has no significance to Solaris itself and is used only by OpenCSW packaging tools. When possible, the catalog name for a package is the full name of the software. When manipulating OpenCSW packages with pkgutil or pkg-get, it is perfectly acceptable to use the catalog name.
OpenCSW imposes a limit of 20 characters on the catalog name, but this is only to make columnar displays nicer in fixed-width terminal. In some cases, this may make the catalog name cryptic too.
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 or pkgutil --update 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 older releases of Solaris than “The latest”. Sun’s companion CD, doesn’t. So, given that we have to compile the full dependency set anyway… and it is commonly newer than what Sun offers… it makes more sense to depend on “our” packages, rather than Sun’s, for consistency and ease of support by us.
Well then how about using Sun’s packages when and if they’re up to date on a machine?
Sorry, (SVR4) packaging dependencies 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.
Where are the Solaris 10 packages?
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 noticeable benefit to compiling on Solaris 10, compared to compiling on Solaris 8 or 9. 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 [AdvancedSparcArchitecture]?
Short answer: because it doesn’t 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.
