This is great idea to measure contents file impact using alternative root patching with empty content file! As usual for great ideas, now it is hard to understand how else it may be measured. Pretty easy and simple method anyone can do.
But anyway why do you came to this conclusion? It is clear from your tests that the time contents file handling is most of the time of packaging. And I assume in real life we always have cold pkgadd/pkgrm (all this differense is mostly because of contents file access because it may not affect delivering new files by pkgadd as I understand). So for one package in will be pkgadd (cold): 3.97s pkgrm(cold): 17.28s versus pkgadd: 1.20s pkgrm: 0.53s This shows real disc operations while files are not buffered - the real impact of slow contents file. For me, conclusion is that we may have more then 3 times faster pckgadd amd more then 10 times faster pkgrm. Without major changes in tools, without revolutionary changes in packaging-patching, just drop contents file into pieces. From convinience point of view it will be also big step forward. We may share for example package content information between zones and we will not need to update each zone contents file every time something installed in global zone shared area. So for 1 package in 10 zones enviroment it will not be 10zone X 2 X 12M. Patches is bit more complicated story because it depends on how many deltapackages are inside patch and who big this delta packages if it is one only then we save as many as we may of one package if it is 50 deltapackages then we save 50 times. In patchadd.ksh dependancy check was switched off, but most likely patchrm.ksh continue to do this check. And this is most likely reason for this. However patchrm is just adding backup-packages so should not be much slower then patchadd. Thanks, Vassili. This message posted from opensolaris.org
