On Tue, Mar 17, 2009 at 09:54:30AM -0700, Stephen Hahn wrote: > unbundleds/DTraceGUI: > > 16. develop/ide/netbeans/dtrace/gui-plugin. "gui-plugin" is a bad > package basename, since it is non-specific. Either > "dtrace-gui-plugin" or "dtrace-gui".
I don't know that we should be terribly concerned about non-specific basenames. In SMF, there are a number of instances of "server" as a service name's basename, but since you can easily refer to "dns/server" or "pkg/server", it works out just fine, and it will here, too. That said, the worse error here, IMHO, is the otherwise empty directory beneath dtrace, speaking for develop/ide/netbeans/dtrace-gui-plugin, too. Though (and I might be wrong here) I believe the "gui" portion is unnecessary, as it refers to the fact that the plugin *is* a gui, which is somewhat obvious, being a plugin for a GUI IDE. Perhaps develop/ide/netbeans/plugin/dtrace is the right direction, assuming that netbeans can and will eventually have more plugins? > unbundleds/GlassFishV2: > > 1. I don't really think we need both "-[number]" and "-v[number]" > conventions. So "glassfish-2". Do we want to keep the dash as well? I don't care too much here, but I'm not sure I'll be that thrilled with .../python-24. I guess there's something about the dash that makes "-24" seem more like "twenty four" rather than "two point four", the way it does when it's more smooshed together in .../python24. > unbundleds/NetBeans: > > *. What's the difference between a component in > develop/ide/netbeans/library/ and a component that's in > develop/ide/netbeans? Do we want a richer set of subdirs of netbeans? Should the language support bits be combined separately? I'd also like to say that I don't really like "develop" as a component here. Let's stick to nouns. I'd be happier with "devel" or "dev", as "development" is probably too long. > unbundleds/OpenOffice: > > 1. Not a system package. Looking at your full fix, I would suggest > either command/openoffice or maybe editor/openoffice. application/openoffice? Or is that too generic? Both command and editor feel a bit low-level to me. Commands are things like ls, or even vi. Editors are more like vi. If application is too generic, perhaps "office" as the class of application? Do we want to stuff that under "application" -- application/office/openoffice, where you might also have application/crm/siebel, application/graphics/photoshop, etc? > unbundleds/Studio: > > 1. Drop "ide", unless we come up with a good reason to keep it. Since it's more than just an IDE, it definitely can't stay, unless we decide to break it out into multiple packages, one of which could be the IDE. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
