From owner-freebsd-ports Sun Jun 2 7:57:17 2002 Delivered-To: freebsd-ports@freebsd.org Received: from bogslab.ucdavis.edu (bogslab.ucdavis.edu [169.237.68.34]) by hub.freebsd.org (Postfix) with ESMTP id 975A037B401 for ; Sun, 2 Jun 2002 07:57:10 -0700 (PDT) Received: from thistle.bogs.org (thistle.bogs.org [198.137.203.61]) by bogslab.ucdavis.edu (8.9.3/8.9.3) with ESMTP id HAA60780 for ; Sun, 2 Jun 2002 07:57:02 -0700 (PDT) (envelope-from greg@bogslab.ucdavis.edu) Received: from thistle.bogs.org (localhost [127.0.0.1]) by thistle.bogs.org (8.11.3/8.11.3) with ESMTP id g52EvO948257 for ; Sun, 2 Jun 2002 07:57:26 -0700 (PDT) (envelope-from greg@thistle.bogs.org) Message-Id: <200206021457.g52EvO948257@thistle.bogs.org> To: ports@FreeBSD.ORG X-To: Edwin Groothuis X-Sender: owner-freebsd-ports@FreeBSD.ORG Subject: Re: Splitting up ports. In-reply-to: Your message of "Sun, 02 Jun 2002 11:43:41 +1000." <20020602114341.C553@k7.mavetju> Reply-To: gkshenaut@ucdavis.edu Date: Sun, 02 Jun 2002 07:57:24 -0700 From: Greg Shenaut Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20020602114341.C553@k7.mavetju>, Edwin Groothuis cleopede: >This kind of reasoning will lead to more extreme things like: >Textproc/libxml is a library to extend the capabilities of other >programs to access/process XML files, so it belongs in lang/ and >textproc/linux-libxml is a library for the linux-emulation to extend >the capabilities of other linux programs to access/process XML files, >so it belongs in emulators/ and textproc/p6-libxml is a module for >perl to extend the capabilities of other perl programs to access/process >XML files, so it belongs into in perl/. It seems to me that the best way to organize the ports hierarchy is solely in terms of ease of maintenance--ports that require similar skills to maintain, such as the ability to program java, should be together. This could make it easier for a maintainer to deal with multiple ports. All of the other attributes of the ports: implementation language, national language, function, level of stability/support, and so on, should be handled through indexing. I've found that script-assisted greps of /usr/ports/INDEX is orders of magnitude more useful than actually hunting through the directories by hand. For example, using a simple "whatport graph data" script (modeled after "apropos") yields |bibview-2.2 -- Graphical interface for manipulating BibTeX bibliography databases |ddd-3.3 -- Data Display Debugger -- a common graphical front-end for GDB/DBX/XDB |p5-GraphViz-DBI-0.01 -- GraphViz::DBI - graph database tables and relations |py-kjbuckets-2.2 -- Graph and set datatypes for Python (C extension) |pybliographer-1.0.8 -- GUI and command-line tools for editing and searching bibliographic databases |qscanplot-0.3 -- A program to extract data from scanned plots, graphs and figures |scigraphica-0.8.0 -- A scientific application for data analysis and technical graphics |steghide-0.4.2 -- Steganography tool to hide data in binary files |xgobi-2001.09 -- Graphical data visualisation tool The search is based solely on /usr/ports/INDEX (which could be improved by adding keywords other than the current subdirectory names). Note that the hits are scattered in several places around the /usr/ports hierachy. I then use another search to follow up, for example using the script "manport xgobi" yields |xgobi-2001.09(math) xgobi-2001.09(math) | |NAME | xgobi-2001.09 -- Graphical data visualisation tool | |DESCRIPTION | An interactive dynamic graphics program for data visual- |. . . | -- Tony Maher | |DIRECTORY | /usr/ports/math/xgobi | | xgobi-2001.09(math) (The script used what it found in /usr/ports/math/xgobi to produce input to nroff -man.) If this is what I'm looking for, I would then use another script ("activate xgobi") to install it either from a package, if present, or via "cd /usr/ports/math/xgobi ; sudo make install". Note that all of this is done without the user really needing to know where in the /usr/ports hierarchy this particular port was located, or what its full version/name is. Back in the good old days, the /usr/ports tree could easily be used to browse through the ports, but I submit that there are now just too many for such a simple approach. Greg Shenaut To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message