On Wed, Oct 27, 2004 at 09:17:41AM +0100, Matthew Seaman wrote:

It would be better, yes, but it would still be playing "hunt the keyword in the stack of 12000 pkg-descrs". If you picked a good keyword you get 200 hits and still have to browse through them. If you pick a bad keyword, you get no hits.

Perhaps if pkg-descr had a KEYWORDS: line and it's use was considered mandatory ... but what are the chances that every port maintainers idea of a keyword is the same as mine?

I think meta-information like fine-grained categories are different than searching.

Oh, I agree that there are tools out there that do very cool things with the ports tree. I'm a regular spelunker (love that word) at freshports.org. That's not exactly part of the FreeBSD tool set on a non-networked machine though, so I don't think it's _directly_ relevant to this discussion.

I'm not even advocating the use of finely-grained categories. I'm just pointing out that searching is not the same as browsing :-). I wouldn't use Google to select the right chapter of the Handbook to read--I'd use the table of contents. Searching is useful, and it's very important and thus worth spending time getting right, but it's a different tool for a different (albeit related) task.

Here's a better example:

Let's say that rather than being the maintainer of the net/latd port, I'm some random user who wants the `llogin` program. So I `cd /usr/ports && make search key=llogin`. But there's no hits.

There's 989 ports in the net/ category. Searching failed. Browsing that directory for the port I want is very difficult. But if there was, say, a dozen sub-categories my task becomes manageable. Maybe in the net/other-protocols (or whatever) category there's only a score of ports. Maybe the name "latd" then rings a bell.

Granted, the ability to search pkg-plist would solve this particular issue. It's easy to find examples where that won't work: if I just want to see what neat kinds of network protocols that FreeBSD has supported in it's ports tree, for example.

-T