>Casper.Dik at Sun.COM wrote: > >> I'm not yet convinced that we need to get rid of the contents file >> to get the performance we are after; the last prototype we did broke >> badly for several reasons (excessive memory use, broken backward >> compatibility). > > >Watch next time during an install; initial packages are added quickly >and as time goes on the system runs slower and slower. Towards the >end of install we're write 15MB to disk to add a 100k package.
That's not what I meant; I don't believe that it is necessary to remove the existance of the contents file; not how it gets there. But it also seems that Peter Tribble statistics don't make this an open and shut case. >What I'd like to see happen here is that the first read of >/var/sadm/install/contents causes a daemon to synchronously >construct a cached, read-only version of the contents file >from the actual contents information; the same file would >be returned to others until pkgadd/pkgrm occurs mandating >the creation of an new file. Why would a daemon need to do that? Just create the file and exit. (pkg tools would then do something to make sure it gets recreated on the next read). This, in my opinion, still points to a solution where the actual database is cached in memory and updated and maintained by that deamon; the daemon can then write the file at irregular intervals (when it has been idle, when the system goes down) and it would be started by any of the package commands). >The Solaris packaging tools would not use this interface; >it would be provided read-only for legacy apps and fingers. > >We don't support running previous versions of packaging tools >on newer versions of Solaris; the Solaris 9 version of pkgadd would not deal well w/ zones, for example. Well, we do, in some sense (live upgrade). So we need to be able to upgrade such a new install root from, say, an S9 system. Unless, of course, you want to backpatch the package tools two releases. Casper
