I'll try to keep these limited to high-level notes ... ---
I think the suggestion to try to make the tail of the name match the tarball name (for the majority of open source components) is a very good one; most people who will be attempting to guess a package name are likely to guess that pretty quickly, and others will likely find things by category in the GUI. --- I'm not sure that "gnu-" is useful for many, if not most of the GNU utilities. I think most folks will think about "ggrep" (the tarball name) if a simple "grep" doesn't work (same thing for "gnu-tar" and "gnu-make", at the very least). There's an argument for coreutils to have a GNU identifier, in case we decide to have the SunOS equivalent, though I'd suggest that "coreutils" is likely not to mean anything other than the GNU version, and that we should pick a different name for the SunOS one. --- > SUNWsongbird command/media/songbird I'd suggest that songbird is probably not a command. Do we want a top-level "media" category that subsumes "audio", "video", and "codec", and maybe "image"? I get the feeling that "command" really ought to be command-line utilities, and not what most people would consider "apps". --- > SUNWclisp developer/clisp Different languages are treated very differently. In particular, larger runtimes (measured by number of packages) like perl and python are in "system", while smaller ones, like clisp, erlang, et al, are under "developer". In addition, plugins/extensions/libraries are treated differently depending on the platform -- php extensions are all "system/php-*-52", perl extensions are "library/perl5/*", python extensions are "developer/python/*", Java libraries are split between "library/java6" and "system/java", and I'm sure each one has a bunch scattered around. This desperately needs rationalization. Proposal 1: put the base language package (including whatever standard libraries it the base tarball comes with) under "system", and all extensions under "library/<language>[<version>]" Proposal 2: put both the base runtime and all extensions under "language/<language>[<version>]". Either way, leave "developer" to tools of various sorts. --- > SUNWerlang-doc developer/erlang/documentation This is just one instance, but probably the first -- there's a lot of inconsistency on how documentation packages are named. I see "doc", "document", and "documentation" all used as full components in various package names, as well as "docs" in others. I'd suggest that the top-evel "doc" category probably should be for things like books -- "diveintopython" seems like the only real candidate that we have currently. --- > SUNWTcl developer/tcl-8 > SUNWtcltls developer/tcl/openssl > SUNWsnack developer/tcl/snack > SUNWTk developer/tk If you're going to version Tcl, you should version Tk, too. --- > SUNWjhrt doc/help/javahelp This belongs with other java libraries. --- > SUNWastfb driver/graphics/ast > > driver/graphics/ast/ast (in case we ever have another AST > package.) > > SUNWastfbcf driver/graphics/ast/config > > driver/graphics/ast/ast/config Do driver config packages really belong in "driver"? That seems sketchy to me. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
