Date: Wed, 27 Oct 2004 08:06:42 -0600 From: Tillman Hodgson <tillman@seekingfire.com> To: freebsd-ports@freebsd.org Subject: Re: ports/www is too full Message-ID: <20041027140642.GB94897@seekingfire.com> In-Reply-To: <20041027081741.GA72488@happy-idiot-talk.infracaninophile.co.uk> References: <20041022074529.GN10363@k7.mavetju> <200410262153.22929.matt@fruitsalad.org> <20041026200121.GS94897@seekingfire.com> <200410270412.59142.benlutz@datacomm.ch> <20041027031306.GX94897@seekingfire.com> <20041027081741.GA72488@happy-idiot-talk.infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 27, 2004 at 09:17:41AM +0100, Matthew Seaman wrote: > About the only way I can see for doing this task effectively would be > a google-like keyword search over the contents of the pkg-descr files. > The pkg-descr files generally contain a pretty good summary of what > the port actually contains -- much better than just relying on port > names. Hmmmm... it should be possible to hook up htDig indexing the > README.html files. 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. > Although did you just try typing in 'apache modules' into the search > facility right on the http://www.freebsd.org/ports/ page? You can > even tell it to just search the package descriptions. 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 -- Page 41: Two of the most important Unix traditions are to share and to help people. - Harley Hahn, _The Unix Companion_
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041027140642.GB94897>