You bring up a good point -- if the shared components and files were separated, would performance benefit?
Perhaps a 'shared' contents file, and a 'files' contents file along with an index? Hmm... probably not, based on the complexity required. Other than that, I have to agree with others on the list. We've got a database of filenames, and to allow select-update operations and better performance, you'll end up with a database access method. A new API for the contents file would be required (something that front-ends whatever the back-end DB might be), but I wonder if that won't need to be there for future flexibility. I personally like the idea of using the built-in postgresql. If it were functional out-of-the-box, DB operations for many of the large flat files could be migrated into the DB. Just a thought. On Dec 14, 2006, at 3:43 PM, James Carlson wrote: > Gregory Shaw writes: >> Would it be practical to break the contents file into an index of the >> packages, and a for each package name? > > We've been over that ground as well. > > The contents file is currently a documented part of the system (see > contents(4)), and, more importantly, there are applications that have > come to depend on it. > > Without that, yes, you can break up the file, as long as you figure > out some reasonable way to handle shared components (such as > directories). As Dave said, there are likely other things that need > to be addressed. > > -- > James Carlson, KISS Network > <james.d.carlson at sun.com> > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 > 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 > 1677 ----- Gregory Shaw, IT Architect Phone: (303) 673-8273 Fax: (303) 673-2773 ITCTO Group, Sun Microsystems Inc. 500 Eldorado Blvd, UBRM02-157 greg.shaw at sun.com (work) Broomfield, CO 80021 shaw at fmsoft.com (home) "When Microsoft writes an application for Linux, I've Won." - Linus Torvalds -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/install-discuss/attachments/20061214/a60affc5/attachment.html>
