I thought Sarah's answers were pretty good in most respects, but I'm not so keen on this one:
>> Database >> -------- >> If there is any way at all possible to use SQL-Light, Berkeley DB, or >> similar >> light database client to offer an option over the "contents" file as we know >> it today, that would be swell. I'm ok with the contents file and amazed it >> doesn't get more corrupt on more systems, than it has. This causes us a lot >> of time during package installation I would guess, but not certain. >> >> > the /var/sadm/install/contents file is one of the reasons it takes time > to do installations. And, it is a single point of failure for sure. As > to the solution, there have been a few bandied about. One I thought had > some promise was doors as files: > http://approach.sfbay/wiki/index.php/Doors-As-Files > We tried replacing this once, and it was a disaster - one of the few projects I can recall being backed out and completely abandoned after integration; it wasn't for lack of effort on the team's part, it just didn't end up providing measurable benefit and carried a great deal of cost. People bring up this idea occasionally, but I always feel it's a solution looking for a problem. Usually the grounds are performance, but I'd suggest reviewing the thread Peter started at: http://www.opensolaris.org/jive/thread.jspa?messageID=31892粔 before proceeding with that argument. And I can't say I'm a fan of "Doors as files"; if your premise is points of failure, I don't see throwing a whole bunch more mechanism in the way as being an improvement in that respect. We can do all sorts of things to make the contents file safer from corruption if that's really the issue (my perception is that it's rarely a problem, but perhaps I'm just not seeing the data). Right now it wouldn't even make my personal top 100 things to do. So, please, let's define and characterize the extent of the "problem" with the contents file before charging at it once again. Dave
