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>