Date: Sun, 02 Jun 2002 07:57:24 -0700 From: Greg Shenaut <greg@bogslab.ucdavis.edu> To: ports@FreeBSD.ORG Subject: Re: Splitting up ports. Message-ID: <200206021457.g52EvO948257@thistle.bogs.org> In-Reply-To: Your message of "Sun, 02 Jun 2002 11:43:41 %2B1000." <20020602114341.C553@k7.mavetju>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <tonym@biolateral.com.au> | |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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206021457.g52EvO948257>