To clarify, there are two kinds of packages I'm talking about: 1. Packages currently delivered to Nevada WOS. I'm currently assuming these will get renamed and refactored in a way that's compatible with other changes happening in WOS to support new packages. No hurry here, but they need refactoring. I'll defer discussing those until later.
2. Packages currently used in Sun Studio which is an unbundled product. Any refactoring we choose to do here won't affect WOS packages, except we'll be able to provide N sensible packages to OpenSolaris instead of just 1 for sunstudio. Currently our S10 and Linux releases have about 60 different packages with gross little 5 letter names. When delivering to OpenSolaris, they are glommed into one 'sunstudio' package. So our first step is to rearrange our own build structure to create the new units we want. The package base names will be used in future S10 and Linux deliveries. The proper hierarchical names for OpenSolaris can be assigned as part of the OpenSolaris delivery process. So that's the background for the task I'm working on now. * 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 I'm not sure I understand the logic of putting any runtime libraries in the "developer/..." namespace. After all, deployed applications would depend on these runtime libraries, and they would need to be installed on systems where no development was going on right? So I would put all user-visible runtime libraries under "library/..." someplace. The 'tools' and 'compilers' packages I liseted above don't contain any user-visible runtime libraries, so they should all go under "developer/..." someplace. If a package contains only one library, I can see calling it "libfoo", but if it contains several related libraries you should call it "foo-libs" or something like that. So perhaps our "scalapack-libs" should be "libscalapack" since it contains one library. I see that SUNWsprot (which contains make/sccs/assembler and the new profile support library) is listed as developer/tool/sun-make-sccs. Is there some logic to the grouping of "developer/tool/*" ? What makes something a "tool"? It seems to be used as a synonym for "misc" or "other". It seems like "developer/c" is not the best container for gcc, since that package also contains fortran and C++ compilers. Perhaps developer/compiler/gcc would be better? I see netbeans is proposed to go under developer/ide/netbeans... With those ideas in mind, perhaps the Sun Studio packages could be: developer/ tool/analyzer debug/dbx ide/ss-netbeans tool/dmake misc/sunstudio developer/compiler/ c c++ fortran backend perflib perflib-interval scalapack library/ c++-libs fortran-libs math-libs (or libsunmath) perf-libs (or libsunperf) scalapack-libs (or libscalapack) There's a bit of management-directed marketing here where we intend to imply that the Sun compilers are the default/preferred compilers for OpenSolaris, so for example the C compiler would be developer/compiler/c and not developer/compiler/sun/c. I really don't think it's a big confusion issue, just a nit. The idea behind the name "c++-libs" is not that it contains all or most c++ libraries, it's a package of runtime libraries released with the C++ front end, by the same team. They're not terribly co-dependant, as far as I know. I wasn't going to split out libstlport from libgc and librwtool.so etc. Similar for fortran-libs. If you got this far in the email, I'd love to get your thoughts and feedback. Even if it's just "seems ok to me". Although in that case, you may not want to cc: everyone. ;-)
