Re: Getting rid of section "base" ?
On Mon, Nov 29, 1999 at 08:02:20PM -0500, Decklin Foster was heard to say:
> Goswin Brederlow writes:
> > Maybe program should be split up further into stuff like games and
> > such. Also where do windowmanagers go? I would like sections for
> > games, graphics, utils, interfaces.
>
> I'd disagree with splitting up the program section; it [being a
> "game"] doesn't seem like much of a distinction. A window manager
> would be in 'programs', and a section of...? Not sure. Perhaps keep an
> 'x11' section for this, Xfree86, XDM, and so on?
No, there definitely need to be a *lot* more categories based on what a
program is or does -- in fact, in my opinion, Goswin's proposal doesn't
define /enough/ of them. For example, I'd like to see net/icq, devel/compilers,
net/web/servers/apache, net/web/browsers/netscape, games/rpg, etc. This is
essential for people who are just looking to see what sort of software is
available in Debian rather than searching for a specific package. I brought
this up last summer and the discussion trailed off, unfortunately. You can see
the mail and followups for a more detailed discussion (I believe I actually
sketched out most of the proposed package hierarchy)
Obviously, such a hierarchy would have to be totally divorced from the
directory structure. As noted in the earlier thread, it would also probably
be useful to allow for packages to be categorized in multiple ways (eg,
web/servers/apache or servers/web/apache) The proposed "Interface", "Nature",
etc tags would solve this neatly (just rearrange the grouping order to get
a different hierarchy and ignore tags you don't care about), but I think some
thought neads to be put into how to do them.
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:
-> File Formats, a listing of all file formats the program can manipulate,
possibly restricted to some common ones and catch-alls,
-> 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 about separating Function and Category, but the intent is this:
everything except Category would have a fixed (in policy) set of possible
values. Category, on the other hand, would be arbitrary. The reason is that
categories would (hopefully) be much finer grained than the other tags, and
therefore more varied; in addition, the categories will be specific to a
particular function (eg, "rpg" doesn't make much sense within the "admin"
section. I hope not, anyway ;-) )
The frontends (well-designed ones, anyway) would allow the user to group
in arbitrary orders -- eg, I might use Function as the top level of my
hierarchy, followed by Nature and then by Category, while someone else might
just split by Function (for that retro dselect feel ;-) ) and a third person
might split by File Formats and then Nature.
As another (minor) note -- I'm not forgetting about main/non-us/etc, I just
left them out ;-) Presumably they'd be handled by another tag, and the user
could group on them as well.
> > > 2. UserInterface: A list of ways the programs in the package interact
> > > with their users. Possible values are to be defined by policy,
> > > examples are given at the top of this mail.
>
> Now, this is *only* with packages marked as a "Program", right? Maybe
> it should be clarified.
I think "daemon" should probably be an interface. Actually, it occurs to
me that "interface" for docs may be something like html or ps. It may be
worthwhile to add a "none" interface -- libraries (such as libgtk) may very
well provide a user interface, but there are plenty (such as libz) that don't,
so some mixing would be useful.
Daniel
--
Voodoo Programming: Things programmers do that they know shouldn't work but
they try anyway, and which sometimes actually work, such as recompiling
everything.
-- Karl Lehenbauer
Reply to: