From owner-freebsd-ports Sat Feb 22 11:12:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id LAA02984 for ports-outgoing; Sat, 22 Feb 1997 11:12:46 -0800 (PST) Received: from fallout.campusview.indiana.edu (fallout.campusview.indiana.edu [149.159.1.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA02976 for ; Sat, 22 Feb 1997 11:12:42 -0800 (PST) Received: from localhost (jfieber@localhost) by fallout.campusview.indiana.edu (8.8.5/8.8.5) with SMTP id OAA16684; Sat, 22 Feb 1997 14:12:35 -0500 (EST) Date: Sat, 22 Feb 1997 14:12:35 -0500 (EST) From: John Fieber To: Paul Richards cc: ports@freebsd.org Subject: Re: Perl5 modules In-Reply-To: <87914htuw1.fsf@originat.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ports@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On 22 Feb 1997, Paul Richards wrote: > The only argument I heard in favour of the current scheme was that if > some hacker was looking for a package to do something, say web > related, then they'd probably go and look in www. ...Which can be (carefully) implemented in via secondary entries in the CATEGORIES field of a port... > It would be so much easier if "real" perl programmers could go to > /usr/ports/lang/perl_cpan/ and see immediately if the package they > want is part of the ports collection or not. A "what it is" classification dictates this approach. A "what it is used for" calssification dictates what we have now. As I've described in the past, the latter can never be done completely, and the more complete it is, the more unworkable it becomes until it is eventually crush under its own weight. The only thing worse is a classification system with an ambiguous policy and/or practice. Predictability is a very important component of usability (with the standard exception of video games). -john