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
"libs")
> > 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..
Daniel
--
"I've struggled with reality for thirty-five years, but I'm glad to say that
I finally won."
-- _Harvey_
Reply to: