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

Re: Getting rid of section "base" ?

On Wed, Dec 01, 1999 at 11:37:50PM +0100, Yann Dirson was heard to say:
> Daniel Burrows write:
> >  No, there definitely need to be a *lot* more categories based on what a
> > program is or does
> I agree, but the official frontend is still dselect AFAIK, and it is
> not able as-is to handle deeper hierarchies in a satisfactory manner.
> This will probably come with modern frontends like gnome-apt.

  There are a couple things that spring to mind here:

  First, someone (forget who) is trying to retrofit dselect to handle
hierarchical display.
  Secondly and more importantly, the current sectioning system is holding back
the more advanced interfaces, and a new and improved sectioning system wouldn't
have to break dselect; it would be possible to just look at the first level
of the hierarchy (possibly using additional information to, eg, reconstruct

> >   Personally, I would like to see the "Nature" tag split between libraries,
> > programs, data, and documentation, the "Interface" tag split
> > between X, console, tty, and daemon (ie, no meaningful UI), and some more tags:
> About "daemon" interface, I'd rather classify a daemon as "Nature:
> server; ClientInterface: whatever-if-useful".  I see 2 orthogonal
> issues here.

  Hmm.  Most daemons don't come packaged with a client, and clients can use
different interfaces (just look at the different WWW or FTP clients..)  Or am
I missing something?

> >   -> File Formats, a listing of all file formats the program can manipulate,
> >     possibly restricted to some common ones and catch-alls,
> This could be investigated using the "language/translator" model I
> succintly depicted in Message-ID: <14405.39784.502704.61623@bylbo.nowhere.earth>
> (same subject, same date, reply to Goswin).

  Hmm.  That sounds somewhat reasonable, except that I don't see how it maps
to a usable hierarchy -- it seems like you'd get an incredible mess if you
tried to represent it.  Could you maybe be a little more specific about what
you mean?  I might just not be understanding your intention..

> >   -> Function, a broad categorization of the package, like the Section: tag we
> >     have now but probably with slightly broader scope.  A quick thought
> >     suggests: admin, devel, system, utils, net, graphics, games, editors, but
> >     I'm sure a better approach can be chosen.
> >   -> Finally: Category, a more narrow description of the package within its
> >     function group.  For example, nethack might declare "Category: rpg", while
> >     gnomeicu might declare "Category: icq".
> I'm not sure I like the distinction between Function and Category.
> Especially as Category is highly dependant on Category.
> I'd rather suggest to have Sections like games/rpg and net/icq.
> We can still have a skeleton hierarchy defined by policy, and allow
> developpers to add ther own sub-sections as they see fit.  If that
> somewhat distributed approach fails, then we'll see and adapt it.

  As I said, I wasn't sure if separating them was a good idea ;-)  Now that I
think about it more, I think that it was definitely a bad idea..


  "I've struggled with reality for thirty-five years, but I'm glad to say that
   I finally won."
     -- _Harvey_

Reply to: