[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Misclassification of packages; "libs" and "doc" sections



On Thu, Oct 12, 2000 at 04:28:50AM +0300, Eray Ozkural <erayo@cs.bilkent.edu.tr> was heard to say:
> Daniel Burrows wrote:
> > 
> >   Ok, I think this is what I meant, except that I was thinking of the UI end.  This is
> > definitely how to do the datastructure, though.  (suggestions as to how to represent the above
> > without resorting to GL [1] are welcome ;-) )
> > 
> 
> What's GL?

  OpenGL -- the canonical 3d graphics API.

> Package: emacs
> Category: main
> Priority: Optional
> Section: editors/devel, devel/editors
> 
> In the second one, there's a package that's in two sections simultaneously
> but the hierarchy seems to be a tree.
> 
> That is
>   
>        Apps
>        /   \
>       /     \
>      /       \
>    Editors   Devel
>      |         |
>      |         |
>    Devel      Edit
>      |          |
>      |          |
>     emacs     emacs

  ..except that in the datastructure, those two emacses are actually one;
the pointers go to the same place.  This looks to me like what you're
proposing.  (this is quite easy to implement)

> Which means something like, emacs is an application which is an editor
> which is a devel tool, or emacs is an application which is a devel tool
> which is an editor. Anyway, this is a tree.
> 
> Whereas in the scheme I offer this would like more like
> 
> ( ---* : arrow to right, means is-a here)
> ( [<package-name>] : indicates package <package-name> )
> 
>       User_Proggy                 Development_Tool        
>        *    *                          *         * 
>       /      \                         |          \
>     Editor   X11_Client(opt)    Developers_Editor  \
>       *           *                *       *        \     
>       |___________|______________ /_________|       Interpreter
>                   |              /                    *
>                   |             /                     |
>  Kitchen_Sink     |            /                    Lisp_Interpreter
>            *      |           /                        *
>             \     |          /                         |
>              \___[ emacs20   ] ________________________|
> 
> 
> Whatever :) I wanted to emphasize that this is a graph rather than a
> tree. Conceptually it may be 100 % wrong, but we have to come up
> with a correct one if we want to solve the categorization problem.

  You can infer this from the above specification.  For instance,
here emacs20 could be defined as:

Packages: emacs20
.
.
.
Sections: Kitchen_Sink, Development_Tool/Interpreter/Lisp_Interpreter, etc

  It's pretty easy to look up the correct section and stick it in..

> > 
> >   [snip -- I'll put this on the ever-growing queue of stuff I want to look at in the future..
> >    hopefully that'll be the NEAR future..]
> 
> You said "this weekend" ;)

  ack!  You're going to hold me to doing what I said? :)

  Daniel

-- 
/----------------- Daniel Burrows <Daniel_Burrows@brown.edu> -----------------\
|         "Note that fires are not restricted to dormitories.                 |
|          Indeed, fire can occur in off-campus residences as well."          |
|           -- Brown University Fire Safety Guide                             |
\-Evil Overlord, Inc: planning your future today. http://www.eviloverlord.com-/



Reply to: