OK, mystery solved. Tom noticed a bug in the code section referred to below. Hence we didn't see the "prior_version=" keyword in our log files. He's filing a pkg(5) bug. Once that's fixed, our adopters will be happy to be able to use this keyword to differentiate between new installs and updates.
Chris Shawn Walker wrote: > Christopher Kampmeier wrote: >> Adopters of UC2 and multi-platform pkg(5) would like to report on new >> package installs vs updates of already installed packages, but it's >> not clear to us how to do so. Currently, a "pkg install pkg-java" >> operation that effects an update of the already installed pkg-java >> package results in the following access log record: >> >> 129.150.36.226 - - [27/Jan/2009:10:02:17 -0800] "HEAD >> /dev/latest/manifest/0/[email protected]%2c0-20.1684%3a20090127t041533z >> HTTP/1.1" 200 - "-" "pkg/7570d3749c6f (darwin i386; 9.6.0 Darwin >> Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; >> root:xnu-1228.9.59~1/RELEASE_I386; user; pkg)" "-" >> "(operation=install;reason=process)" >> >> Note that the "operation=install" setting is the same as what is used >> when a new package installation occurs. >> >> Is there a straightforward means based on log inspection to >> distinguish between new package installs and updates to existing >> packages? >> >> If not, is there support for an RFE to indicate explicitly in the >> HEAD requests whether an operation is a new install vs an update? > > The trick is that a keyword will appear in the intent header called > "prior_version" if a previous version was already installed (look at > lines 237-252 of modules/client/retrieve.py in the gate tip). > > As for operation=install being there for an update, that will only > happen if you're not using image-update to update a package. Install > is indeed the operation. > > Cheers, _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
