From owner-freebsd-ports Sun Jun 2 19:23:11 2002 Delivered-To: freebsd-ports@freebsd.org Received: from aaz.links.ru (aaz.links.ru [193.125.152.37]) by hub.freebsd.org (Postfix) with ESMTP id A193537B405 for ; Sun, 2 Jun 2002 19:23:06 -0700 (PDT) Received: (from babolo@localhost) by aaz.links.ru (8.9.3/8.9.3) id GAA10338; Mon, 3 Jun 2002 06:23:34 +0400 (MSD) Message-Id: <200206030223.GAA10338@aaz.links.ru> Subject: Re: Splitting up ports. In-Reply-To: <200206021457.g52EvO948257@thistle.bogs.org> from "Greg Shenaut" at "Jun 2, 2 07:57:24 am" To: gkshenaut@ucdavis.edu Date: Mon, 3 Jun 2002 06:23:34 +0400 (MSD) Cc: ports@FreeBSD.ORG, rehsack@liwing.de From: "."@babolo.ru MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 Greg Shenaut writes: > 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 I found that your proposition is the best with the Jens Rehsack's proposition about data base. And PostgreSQL as a tool to seek in such a ports tree. And mantain ports on commiters side. The only dark side is that PostgreSQL is not in base system :-( -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message