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.
Another possibility which I mentioned earlier to Rich and Stephen would
be to create a "/gnu/" component name that could be used where packages
that deliver "official" GNU components can put their things. That
would result in something like
command/gnu/coreutils
command/gnu/findutils
command/gnu/gpg
command/gnu/grep
command/gnu/mc
command/gnu/patch
command/gnu/tar
command/gnu/which
editor/gnu/emacs
editor/gnu/emacs-gtk
editor/gnu/emacs-lisp
editor/gnu/emacs-no-x11
editor/gnu/emacs-x11
(etc)
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".
What is one of the level 0 questions I had. Is command for CLIs as
opposed to the general set of "applications" which might include GUIs,
etc?
And if that's the case, is it only for those set of commands that don't
otherwise fit in one of the top-level categories such as "editor"?
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>]"
Assuming they're factored this way. :-) Of course if we go this route,
this is excellent advice to the package maintainer for new packages.
Proposal 2: put both the base runtime and all extensions under
"language/<language>[<version>]".
Either way, leave "developer" to tools of various sorts.
That seems reasonable to me - if I had a preference, it would be with
the first proposal.
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.
Seems reasonable to me.
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.
Agreed.
SUNWjhrt doc/help/javahelp
This belongs with other java libraries.
Agreed.
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.
How about system/library/fbconfig/modules/<driver>?
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
