On Mon 31 Mar 2008 at 02:12PM, Stephen Hahn wrote:
> | 2.2. Locally reserved namespace
> |
> | The top-level "site" category is reserved for use by the entity that
> | administrates the server. Neither the organizations producing the
> | operating system nor those providing additional software components
> | may use the site category.
> |
> | The top-level "vendor" category is reserved for use by organizations
> | providing additional. The leading subcategory must be a domain.
Providing additional what?
> | That is, if example.com wishes to publish the "whiskers" package in
> | the vendor category, it would use a package name like
> |
> | pkg://opensolaris.org/vendor/example.com/whiskers
I know this might seem stupid at first, but can you elaborate on what it
means to be a vendor? Some examples of what would and would-not be a
vendor would help. I wasn't sure if the following would go into "vendor", or
not?
- Sun "add on products?
- Open Source Projects not affiliated with the OpenSolaris
community?
- Software which requires the user to acquire a paper license to
run?
I'm just trying to get at what the boundaries are.
> | 2.3. Additional reserved namespace
> |
> | The top-level "cluster", "feature", "group", "metacluster", and
> | "service" categories are all reserved for future use.
You might want to consider further carving out a part of the top-level
namespace...
> | 2.4. Single namespace conventions
> |
> | 2.4.1. Discussion
> |
> | Packaging systems and distributions appear to have explicit
> | categories, subcategories, and potentially larger groups; some
> | distributions have explicit fields for these values, others use
> | tagging or multi-valued fields, which allows them to classify
> | certain packages multiply. For the FMRI namespace case, the system
> | is similar to a packaging system with multiple, single-valued,
> | category fields.
> |
> | There appear to be two standard approaches to categorizing packages:
> |
> | 1. By what primary class of thing a package delivers.
> |
> | 2. By what area of functionality a package's contents address.
To my mind, putting the focus on end user tasks and roles is what's
important. Thinking in terms of a GUI or a website-- we should think
about how user will "drill down" trying to find what they are looking
for. I know first hand how frustrating this can be.
I realize that tagging can fill some of this role.
At the same time, I was a little concerned by the "web/firefox" example:
I'm concerned that we'll wind up with "sprawl" at the top level--
everyone who invents some new thing will be lobbying for it to be at the
top level. We could wind up with 50 top-level categories without too much
effort, I think-- and then it's confusing all over again.
I tried building out an example of what I might like to see, and came
to an idea the there were some broad categories of software that people
might like to access, depending on the role of the machine, which I
see falling into roughly one of three categories:
- Server
- Consumer style desktop (anything from home user to call
center to CAD engineer)
- Developer style desktop
I also reviewed the example (from Alan's mail) and found it to be really
complex-- I didn't feel that I'd ever think to look in application/x11
if I was trying to get a new video driver. Putting on my "new user"
hat: The "graphics subsystem" is part of the *system software*-- it's
not an application I install on the system.
I also found the set of places that one would need to stick packages to
be too large and too unweildy. Here is a straw proposal of what I think
might make sense; it is no way perfect.
desktop/x11-util
(xkill, xauth, etc)
desktop/application/openoffice
desktop/web/firefox
desktop/web/dillo
desktop/mail/thunderbird
desktop/mail/evolution
desktop/editor/xemacs
developer
developer/compiler/gcc4
developer/ide/netbeans
developer/lang/python
developer/lang/java
server/web/apache
server/web/cherokee
server/appserver/glassfish
server/appserver/jboss
server/db/mysql
utility/text/less
utility/text/vim
utility/mail/mutt
system/library/c
system/core/kernel
system/core/driver
system/core/fs
system/x11
(video drivers, input drivers, x11 libs, fonts, cursors,
autoconf, etc.)
To back up: I don't have a strong conviction here, except to say that I think
that in either case, "system" should be used to contain stuff like the kernel,
drivers, and perhaps core system libraries and stuff like the X server.
Other, non-core libraries I'm less sure about. Yes, I know that the definition
of "core library" is vague.
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
