Date: Mon, 3 Jun 2002 06:23:34 +0400 (MSD) From: "."@babolo.ru To: gkshenaut@ucdavis.edu Cc: ports@FreeBSD.ORG, rehsack@liwing.de Subject: Re: Splitting up ports. Message-ID: <200206030223.GAA10338@aaz.links.ru> In-Reply-To: <200206021457.g52EvO948257@thistle.bogs.org> from "Greg Shenaut" at "Jun 2, 2 07:57:24 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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
I found that your proposition is the best with the Jens Rehsack's
<rehsack@liwing.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206030223.GAA10338>