I'm reviewing the package organization and names for the packages
delivered by the compilers and tools org. This includes some Nevada
packages, and whole bunch of unbundled packages that are normally
hidden by our installer, or glommed together into "sunstudio"
for purposes of OpenSolaris. I'm planning to use the word
"core" to distinguish between libraries heavily depended on by
the current Solaris packages, and other libraries coming in
from an unbundled tradition. So for example "c++-core-libs"
would be the new name for SUNWlibC, and "c++-libs" would
have additional C++ shared libraries that normally ship with
the compilers. I'd like to review the base names for these
packages. In OpenSolaris I expect the package reorg project
to provide us with input for choosing a hierarchical location,
but I'd like to be able to stick with the base names that
I'm choosing now without waiting for the whole package reorg
project to get settled. Is that realistic? Anyway, I'd be
glad to have feedback on my choice of names here.
Nevada packages:
SUNWcpp --> cpp
SUNWlibC --> c++-core-libs
SUNWlibm{,r,s,sr} --> SPLIT: math-core-libs, multi-tasking-libs
SUNWmlib* --> media-libs
SUNWsprot --> COMBINE 2 old packages/SPLIT into 4 new ones:
SUNWxcu4t --> make, sccs, assembler, profile-support-libs
Sun Studio packages:
* Tools: analyzer, dbx, dbxtool, ss-netbeans, dmake, studio-common
* Compilers: c, c++, fortran, backend, perflib, perflib-interval, scalapack
* Runtime Libraries: c++-libs, fortran-libs, math-libs, perf-libs,
scalapack-libs
Our intention is to deliver the Sun Studio runtime libraries into /usr/lib,
but I'm assuming that an independent discussion from the base names of the
packages.
Additional gory details:
The studio-common package will be necessary for odds and ends related to Sun
Studio
as a product, that we haven't merged properly with Solaris yet. For example,
registration support, usage tracking, etc. These files are shared dependencies
of multiple other packages in Sun Studio that otherwise have nothing in common.
The ss-netbeans package is planned based on our existing SSIDE implementation,
and contains a copy of NB. When the SSIDE team can deliver a module that plugs
into the NB packages delivered by the netbeans team, the package would be named
similar to other netbeans modules (IE: "netbeans-something") and it will contain
only the modules that add SSIDE support.
The perflib and scalapack packages contains static libraries and man pages, and
are considered part of the compier. The perf-libs and scalapack-libs packages
contains the runtime libraries. Only the *-libs packages will be needed as
dependencies
of software built with our compilers.
--chris
