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

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



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?

Daniel, we clearly have some disagreement here :) You just have to
look at the hierarchy graph to see what's different. In your other
posts in this thread, you give as example:


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

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


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.


> > An example is release management. If subsystem boundaries are small
> > compared to inter-subsystem dependencies then a subsystem can be
> > released as a sub-distribution; the release management can be decoupled
> > from that of other sub-systems. Also each subsystem may have different
> > formal requirements, in other words this is for implementation of
> > the distribution, not the interface :) A user would be less
> > interested in this.
> 
>   ah, ok.  You may want to look through the archives; people suggest this periodically,
> although I don't think anyone ever gave quite such a detailed explanation.
> 

I'm suggesting it periodically. :) If there's anybody else I'd be
pleased to know. Does it date back to package-pools rose war? [An
internet discussion in which everybody finds the other parties
right and comments on how smart they are :), and most probably nothing
gets done in the end :) ]

> 
>   [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" ;)

If we could devise an external way to categorize packages (packages
doesn't have to be mod'd), than we can start a "Debian Ontology Task
Force", and hack together an ontology.

Keep categorizing,

-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo



Reply to: