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: <[EMAIL PROTECTED]> > (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_