Date: Wed, 11 Dec 1996 15:19:50 -0500 (EST) From: John Fieber <jfieber@indiana.edu> To: Satoshi Asami <asami@freebsd.org> Cc: ports@freebsd.org, www@freebsd.org Subject: Re: ports/2190: need cross-reference to xpdf from X11 ports tree Message-ID: <Pine.BSI.3.95.961211141732.2276C-100000@fallout.campusview.indiana.edu> In-Reply-To: <199612110118.RAA16308@silvia.HIP.Berkeley.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Dec 1996, Satoshi Asami wrote:
> * On the ports web page, xpdf is listed under graphics, but not under
> * X11. I looked under X11 first, and not finding it, assumed that it wasn't
> * ported to FreeBSD. Shouldn't there be a crossreference here somewhere?
>
> The "x11" category is not intended for X applications (otherwise half
> the ports tree would be there),
With respect to xpdf, on the three occasions I've updated my
port, I've always had trouble finding it as I instinctively
equate postscript with two-dimensional static media, namely
"print". I think a cross refernce there would be quite useful.
> There also should be a way to add a short "comment" field to the
> category name, as currently the ports web page doesn't include one and
> is sort of cryptic.
[WARNING: rambling ahead]
Back in the good old days when the ports collection was small,
finding things in a primative organizational scheme was easy.
Now that the collection is growing by leaps and bounds, the
interface to the collection itself becomes more critical.
Activities range from simply finding new ports, to knowing what
versions of what ports you have installed, being alerted when
those particular ones have been updated (including update
summaries), semi-automated retrieval and installation ("Click
here to install") and the like.
Most of this boils down to database operations. When thinking
about how to improve on the www interface (and there is lots of
room for that!), I keep scratching my head thinking "gee, if this
stuff were all in a relational database, this would be a snap!".
The ports collection meta-information is set up well for
orchestrating the building of ports, but as a database, it seems
a little ad-hoc.
Cvs is handy for version control on individual files, but
pathetic for just about any other sort of database type task. It
is sort of like a library catalog where the only available search
key is the call number. The ports collection clearly needs more
than that, thus the creation of a secondary database, currently
in the form of the INDEX file. Generating this repeatedly from
scratch is terribly inefficient. What is needed is a secondary
database that is updated in real-time as the cvs repository is
updated.
I'm no cvs wizard, but it should be possible to plant a hook in
cvs to manage the updates in real-time as commits are made. A
script would only need to know the name of the single affected
port and it could then collect whatever information is needed for
a rich, rapid access secondary database. This strikes me as
being phenomenally more efficient than re-scanning the entire cvs
port collection and rebuilding the INDEX file from scratch every
time. This could also serve as the basis for a client-server
ports/package management system, allowing people to keep their
*installed* ports up-to-date without having to have the ports
collection itself installed locally. Again, as the ports
collection grows, keeping a local copy becomes more of a problem
for people tight on disk space.
Anyway, to the point, I think its time to start a closer
evaluation of the ports mechanism from a access interface
standpoint and see how things can be improved. In a year or so,
when we have 3274 ports, I think the current arrangement will
become rather awkward!
Okay, I've got two more term paper to write in the next couple
days. More later...
-john
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.961211141732.2276C-100000>