[email protected] wrote: > 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)
Yeah, I guess. I'm not sure about components which are unique, like gpg, even if they are under the GNU project umbrella. For the GNU components which are just reimplementations of UNIX commands and libraries, it makes plenty of sense, but maybe not for others. Also, I'm not sure that we really want to have brands used that way in the package namespace. If a component gets added to or removed from the GNU project list, do we change its name? Ultimately, I guess I don't really care too much. > >>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? That's roughly my feeling. > 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"? Probably, yeah. > >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. 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>? Except that then "<driver>" won't be a unique tail. Should the driver package simply include the config bits, or do people want to minimize those out? Perhaps there could be a facet for this kind of thing? Or just call it <driver>-cfg? Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
