Danek Duvall wrote:
>> developer/
>> tool/analyzer
>> debug/dbx
>> ide/ss-netbeans
>> tool/dmake
>> misc/sunstudio
>
> ss-netbeans and dbx seem right; I'm don't care one way or another about the
> "tool" subcat so those could go there or directly in /developer, and I
> guess "misc" is as good a place as any for the common studio packages.
> Could you describe a bit more what goes in that last?
Actually my latest name for that package is "studio-common". It contains
all the cruft related to the sunstudio "product" that we haven't moved to
a better place yet. It has utilities related to active user tracking, and
any other dependencies that are still private but shared between the tools
and compilers. (Sun Compiler shared internal goop goes in the "backend"
package)
studio-odds-and-ends would be a better name, I don't want anyone to install
"studio" and think they're getting Sun Studio.
>
>> developer/compiler/
>> c
>> c++
>> fortran
>> backend
>> perflib
>> perflib-interval
>> scalapack
>
> Seems fine. I don't have a strong opinion about grouping all the compilers
> in a suite together, rather than splitting them up by language, but either
> would work. I'm dubious about the up-leveling of the components here,
> though (without a "sun" or "studio" in the middle). Note that you'll be
> able to refer to a package by its smallest unique subcomponent, so you
> could still run "pkg install c c++", even if that expanded to
> /developer/compiler/studio/{c,c++}. I don't know if that's a sufficient
> compromise for your marketing folks. I agree it's not terribly confusing,
> but it's a bit presumptuous, and, IMHO, gratuitous.
I think we'll uncover a few more usability issues around automatically
resolving the basename to the full package name. Because we're doing that
I think we need to lean heavily towards a very shallow hierarchy to avoid
confusion. As a made-up example, netbeans/c++/compiled-headers/parser would be
bad,
(even if we had multiple packages at each of those levels)
we should prefer: netbeans/c++-compiled-headers-parser so that user's won't
try to install just "parser" and a different "parser" package than the
one they got last month.
> How will the standard C++ libs (libC, libCrun, libCstd) be handled in the
> new world? Is it possible to start delivering them once, rather than both
> here and in SUNWlibC (or whatever that package gets named)?
The c++-libs package includes shared libraries that are disjoint from SUNWlibC.
For now my plan is that the SUNWlibC libraries will be reorganized and renamed
when other Nevada packages start undergoing the same process.
--chris
