It's not clear what qualifies as "gnome2" For example, I'd say bluefish does not. It has a gtk-based front-end but that's it. Apart from that, it would gladly run on KDE, Xfce or anything else. In fact, Xfce has very few "commands" (I'll get back to this later) of its own, it runs GNOME applications. Similarly, Qt-based apps can be run on GNOME (e.g. VirtualBox) just fine. Some projects can be built with different toolkits. So I would suggest separating desktop environments and desktop applications.
Can you provide a list of all of the existing packages you would put under a "gnome" (sub)component name? That might be the top-level or perhaps something like library/gnome?
What's under these categories is the next issue. "command" doesn't make any sense to me. Many projects have "commands", libraries, Python modules, documentation, localisation, etc... If we don't intend to split them up along these lines, we shouldn't throw them all under something like "command".
I'll let Stephen answer this although as Danek pointed out, perhaps "command" makes sense for CLI-based applications that don't otherwise fit into the other top-level components? And system/command would be for commands that are typically not used by end-users (the old /usr/bin versus /usr/sbin split!?)
I agree with those who suggested that the basenames should match the project names, e.g. gnome2/file-manager/nautilus, gnome2/accessibility/screen-reader/orca. I also find the proposed GNOME library renames confusing: some libraries under system/library/gnome2 others under library/gnome2
Again, understanding what components belong in "system" would help. For example, I would expect few applications writing to the PICL specification and so perhaps those libraries (if the package was factored this way) would end up in system/library/picl. But I would expect the GTK2 library to be in library or perhaps gnome/library.
and then again, several GNOME libraries come with the applications, so I assume those would not be split out. Python modules, however, should be split so they can be built and packaged for several different Python versions and I think all Python modules should live under Python categories, something like: system/python/python24 system/python/python26 python24/pygtk python26/pygtk python24/mysql-python python26/mysql-python
Rich's proposal had most of these under library/python2 which doesn't preclude having separate packages for separate Python versions. But I'm not adverse to the idea of having an extra component there to contain all of the libraries for a particular version (again, assuming they're packaged that way.)
Localisation and documentation should be facets of the packages, not separate packages. I know we are not there yet with the installer, but perhaps we should just leave those packages alone then rather than introducing new package names that will go away soon.
If we really can't figure out a decent place for these packages, I might agree but there may be a sensible name that makes sense in the short-term. _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
