portindex -- the second coming.

[Christopher Nehren]

On Sat, 2004-10-23 at 10:22 +0100, Matthew Seaman wrote:
> I have absolutely no objection to that, although what I wrote might
> not be the best starting point.  I just dump what is essentially the
> 'make describe' output into the DB file as an opaque lump, and all of
> the dependency accumulation is done in the front end portindex
> process.  What you're describing implies doing quite a bit more
> dissection of the data to fit it into a proper RDBMS schema, and
> having done that, moving much of the processing required into the SQL
> back end would only be sensible.

All good points, I agree completely. 

> I'd be against making it a requirement to install a RDBMS back end in
> order to use portindex though.  I'm half minded to make the dependency
> on BerkeleyDB optional as well -- there's no reason why portindex
> shouldn't work using the standard DB_File bundled with perl, and the
> db1.86 code bundled with the system, so long as that annoying bug has
> been patched.

Again, I agree. This is where a data store abstraction layer would be
very helpful. I mentioned C::DBI and Alzabo above, but I think that
they're much too powerful for this.

I presume that by "annoying bug" you mean "portindex uses the port
origin as its unique key in the data cache."? If so, that shouldn't be
too difficult to solve. "make index" has to obtain its correct concept
of the package name somehow. It shouldn't be too difficult to do the
same thing.

> I suspect that Dan Nelson, of freshports.org, probably has pretty much
> exactly the code you're looking for (PostgreSQL back end and all),
> although I have no idea if he would be prepared to release any of it.

Oooh, great idea. I'll look around the website and see if I can't find
any information about said code. 

> I also noticed this morning that there's already a FreeBSD::Ports
> module in the tree (by Tom Hukins) so I may have to do a bit of
> renaming.  Plus I'll be putting out an update shortly so that it deals
> more gracefully with various ports breakages, like:

Hmm, perhaps you could put your Ports.pm in the Portindex namespace?
That's probably the safest way, and it implies a "has-many" relationship
to me which makes sense.

Here's the feedback that I promised earlier: I very much like what
you're doing, and your code is very clean and well-written. However, I
have one minor nit: I'd like to see portindex determine which ports need
to be updated by checking the mtime / ctime (at least I think that it
was one of these, because it worked without cvsup output and only
updated those which were out of date) on the relevant port files, like
the original portindex did. Not everyone uses cvsup to update their
ports tree, and not everyone uses cvsup to update all of their ports
tree. I do beta testing for the development versions of GNOME, and I've
been trying out the BSD# ports tree as well. While the development
version GNOME ports tree does have a cvsup server, the BSD# ports tree
doesn't (I may be wrong on this; if anyone's reading who knows better,
please chime in). There's probably other development trees that people
graft onto their real tree which don't use cvsup as an update avenue. Of
course, since I mentioned it, I'll be glad to implement it.

Best regards,
Christopher Nehren

-- 
I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated".  -- Ken Thompson
-
Unix is user friendly. However, it isn't idiot friendly.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20041023/3f5ce336/attachment.bin