On Fri, 28 May 1999, Miles Nordin wrote:

> I think this is inherently unclear enough to evolve toward uselessness.  I
> see two problems immediately:
> 
>  1. TYPE is a concept that only exists for a few packages--those which are
>     redundant, have competitors: like web servers, word processors, X11
>     clocks.  For most packages, TYPE == category.  Intuitively, this is
>     not so, but if you look through pkgsrc it soon becomes depressingly
>     apparent that, basically, it is.  What ``type'' of package is CVS?

  The same type as RCS :).  Maybe "revision control systems."  As you
mention, it is not so important exactly what they are called as long as
similar ones are grouped together.  This certainly tells you more then
"developer utilities."  It is supposed to be much more specific then the
category, even more specific then the general application it concerns.
i.e. "irc server" and "irc client" and "irc bot" are all irc
applications, but people who are interested in one are not necessarily
interested in the others.  And all of these are currently in the same
catagory as coda and bind4.  Currently, you would have to grep COMMENT to
find similar TYPE applications, which might not work if the package
creators used differet wording.  It may not be too hard to read each one
when there are 50 packages in a category, but what happens when there are
500?  And does a www library go under www or devel?

  Actually, it would probably be more useful to all packages to have
several types, so, say, an office suite could have type "word processor",
"spreadsheet", etc. and maybe also "office suite."  Similarly, a p5 CGI
module might have types "perl5 module" and "CGI library."

>  2. Even where TYPE's are useful, TYPE's are poorly defined and easy to
>     argue about. So are categories, but at least with the categories
>     there are a few established broad categories to choose from.  
>     Clearly, the purpose of TYPE's is for two or more packages to have 
>     identical TYPE's and thus indicate some kind of association, but 
>     compared to categories, TYPE's would be (a) more numerous, and (b)
>     stored in pkg/TYPE, two factors which combine to make falling into an
>     existing type less likely.

  (b) could be worked around by creating a pkgsrc/Types.txt file that
lists all possible types (I ment to say this before but forgot to mention
it).  (a) is the whole point of the idea.  While general catagories are
very good to have, it would also IMO be good to have a way of locating
applications more specificly.  

> It sounds like the logical impact of your suggestion would be better
> accomplished by a tree-structured category system replacing the current
> single-level-deep system.  I think this is a bad idea because
>  (a) the current system works well, and
>  (b) CVS doesn't deal well with moving directories around.

  I agree this is a bad idea.  This is why I suggested a pkg file instead
of directory reorganization.

> Perhaps a better implementation of pkg/TYPE would use a special syntax to
> maintain the hallucination of a deeper category tree, superimposed upon
> our current one-level tree.  This is basically the same as what you said,
> except that the bytype/ symlink spaghetti is more than one directory deep,
> and it implies an understanding of objection (2) above.  Objection (1) is
> solved by assuming TYPE==category when pkg/TYPE does not exist--so the
> package appears in exactly the same spot under bytype/ as it does in the
> main category tree.

  Do the current *.html files appear in the CVS tree?  I don't think they
do (they aren't in the main sup anyway...)  This is why I suggested that
the bytype directory tree (however it is designed) be autogenerated.  This
way, those that want it can crate it while CVS does not have to worry
about it.  It may be that there would be too many TYPEs for a directory to
make sense, but at least there would be an easy way to search for
applications of one type.

> The current one-word category, one-line COMMENT, one-paragraph DESCR makes
> sense to me.  While I don't strongly object to a pkg/TYPE, I don't
> understand why you desire it.  If anything, I'd want an optional pkg/RANT
> that isn't used by any of the targets, in which a packager can document
> and discuss absolutely whatever pleases him.  As you can imagine, I often
> find myself writing things that are too wordy to go in DESCR (if i ever
> get around to submitting a package).  I'm not suggesting this--just giving
> an example of something inane that's more useful than TYPE's.

  If I'm looking for an irc client, I want to be able to list all irc
clients in the package system.  I don't care about coda or bind or archie
or irc servers or anything else in the net catagory, I just want to see
the irc clients.  TYPE is just a more organized way of doing this then
searching COMMENT for text that the package maintainer may or may not have
put in the description.


Matthew Orgass
darkstar@pgh.net