Stephen Hahn wrote:
* John Rice <[email protected]> [2010-01-07 07:18]:
Peter Tribble wrote:
On Wed, Jan 6, 2010 at 10:01 PM, Shawn Walker <[email protected]> wrote:
On 01/ 6/10 03:58 PM, Peter Tribble wrote:
Won't users always want to use the short form?
In that case, why inflict the hierarchy on the actual package names?
Just use the basename as the package name, and it's what the user
types, and is unique.
Dropping the category hierarchy has some significant advantages:
- It keeps the package names short and simple
- there's a direct mapping between the user expectation and the
package name
Having the category as additional package metadata rather than part
of the name would be a win in several areas:
The category ("classification") is already separate. Please don't confuse
package namespace with classification.
I wasn't; but now I'm concerned. You're saying that there is both
categorization and a namespace hierarchy? Either they match or
they don't; and are either unnecessary duplication or causes of
confusion.
It is really important to the GUI that we have some sensible way to
strip off redundant categorization information from the package
names, when displaying these packages in a Category a user has
selected.
See: 9437 current multi-part name algorithm is goofy
The only sensible way to do this with the current scheme is to make
sure that the first categorization metadata in info.classification
(allows for multiple classifications) matches the first portion of
the hierarchy name for that package. If it does we can strip it when
displaying the name if the user has clicked on a specific category.
I think you mean that the Package Manager will only use the
org.opensolaris.2008 schema from the info.classification property.
Right?
Yep
I guess I don't see the need for a forced agreement: why wouldn't you
take the list of packages in the selected category, and determine how
much of the FMRI you need to display to make them unique? That is, if
all of the final components are distinct, display only final
components. If not, display one more component--either on all of the
packages, or only on those in conflict. Repeat until no conflicting
displays are present. Use tooltips to show the full FMRI if hovering.
If as Chris and others have suggested we go to using the project names
as the base project name, then hopefully there won't be many conflicts
and this can be done quickly. We'll try it out.
In one past discussion, some non-developer users wondered why we were
emphasizing the FMRI/technical package identifier over the package
description. Maybe we should focus on cleaning up the descriptions
after a basic algorithm is available?
Yep the descriptions are very poor, just look at the openoffice package
for instance. Users expect some meaningful content in the descriptions
in many packages today there isn't.
If they click on the All category we might choose not to strip them
at all of course.
I think having to continue with the current special categories
approach is bound to fail in the long term.
There are aspects of the special categories I would like to see moved
out of info.classification, like those involving bundles,
core/non-core, and potential notability, and into either separate
properties or into the FMRI namespace (when relatively constant).
Ok
JR
- Stephen
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
