Re: Misclassification of packages; "libs" and "doc" sections
On Tue, Oct 10, 2000 at 05:18:55PM +0900, Junichi Uekawa <dancer@netfort.gr.jp> was heard to say:
> Trying to make hierarchies will probably fail, because we don't seem to be
> able to agree on a set hierarchy.
This has been suggested before. I would like to claim something else:
if we DON'T have some default hierarchy, attempting to implement a scheme like
this is almost guaranteed to fail in its goal of making it easier to find
packages. In fact, it is almost certain to make it more confusing, simply
because of the huge number of variables involved. I've tried to navigate
bug-tracking systems and search engines that only provide an amorphous set
of "keywords", and I've never been able to use them effectively compared
to ones that use arbitrary and imperfect hierarchical organizations.
Note that I'm not *opposed* to keywords, we could even use them
to generate any and all displayed hierarchies; I just think that we really
need a reasonable default hierarchy that the packages fall into (which might
not even include all possible keywords).
> I'm looking at "Provides:" now, and it looks promising if we extend its notion.
> We could use a "Section:" based on "Provides:" syntax.
>
> For example, XEmacs is an editor and an emacs, and also a MUA, and Programming
> environment, so it would be
>
> "Section(or Provides): editor, emacs, MUA, Programming-environment"
This really alters the semantics of Provides. Provides has a specific
meaning which relates to the package dependency tree and is not a way of
indexing software!
Moreover, a set of unordered keywords is (--IMO--) not a very good way to
go about indexing stuff, since it doesn't lend itself to producing hierarchies.
If you're wondering why the emphasis on hierarchy, read my previous (very
long) mail, "Request for more finely grained classification of packages", at:
http://lists.debian.org/debian-devel-9907/msg01491.html
Beware the parentheses! (I seem to have a bad habit of writing little
parenthetical comments..) I missed some useful ideas (such as packages
appearing in multiple spots in the hierarchy), but I explained some things much
more fully than I have time to right now (including posting a full example
hierarchy which I still think is a much better approximation to something
usable than what we have now)
(I also got into a long discussion of "package components", which are
probably less important than getting a reasonable hierarchy.
I can hunt down and repost if everyone is interested); in essence, hierarchies
have the critical feature of **not overloading the user with information**.
Choosing between 20 or 30 items is a pain, especially when they overlap in
subtle ways ("music" vs "mp3 player"? "editor" vs "programming-environment"?)
Providing mostly-orthogonal groupings and subgroupings is a natural way to
think about a collection of `objects'. There will always be nasty edge cases
(think about the platypus..), but we can probably minimize these by allowing
things to appear in multiple places if desired.
I think that what might be useful is a set of "tags"; eg,
Package: xmms
Category: main
Priority: Optional
Section: sound/music/players
Formats: mp3, mod, wav
Package: emacs
Category: main
Priority: Optional
Section: editors/devel, devel/editors
(the "Section" tag could maybe be broken up more, but I believe that we need
at least two levels of hierarchy there..splitting the sublevel into a
separate tag makes it difficult or impossible to have something be in both
editors/devel and devel/editors)
These could also be stored in files external to the package control files and
to the Packages file, if desired. (so Packages could contain a subset of all
possible tags) The final result in the frontend would be a hierarchy where each
level corresponded to one set of tags. (this isn't perfect, but it's hard to
imagine another system which is reasonably easy to configure for the user)
For what I think would be a reasonable default hierarchy, check out my
previous mail.
One of the original goals of aptitude was to easily support such a system if
and when we agreed on one. In fact, at least one comment in the above post
("There's one other really essential thing; we need a package-management
interface that will allow you *to collapse and/or hide these hierarchies*)
was almost a direct precursor to the start of the aptitude project several
months later. If people are interested in experimenting with this idea
right now, they are welcome to check out the cvs tree from Sourceforge [1] and
play with it. (due to this being a design imperative, the mechanisms for
grouping packages are quite flexible, IMO. Not that I'm biased at all ;-) )
Once I deal with the more basic UI issues I'm tackling right now,
I want to get back to trying out this sort of thing.
Daniel
--
/----------------- Daniel Burrows <Daniel_Burrows@brown.edu> -----------------\
| "You mean, you'll drop your rock and |
| I'll drop my sword and we'll just try to |
| kill one another like civilized people?" |
| -- "The Princess Bride" |
\------------- Got APT? -- Debian GNU/Linux http://www.debian.org ------------/
Reply to: