I was asked to explain bit more what is recursive patching. Patches and packages may depend on each other. For example webserver need networking support, so in webserver package SUNWwebserver metadata we state that it depends on SUNWnetwoeking, so if you attempt to install SUNWwebserver it will tell you that SUNWnetworking should be installed prior to it, otherwise it will not work.
Similar dependency exists for patches - bug fix in webserver need different bug fixed in networking, to control this in the patch WEBSERVER-05 which delivers webserver fix we state that it depends on NETWORKING-12 patch which delivers needed fix for networking. So when you attempt to update SUNWwebserver with WEBSERVER-05 patch it will check if NETWORKING-12 installed otherwise it will refuse installation. Checking this dependency is most complicated task performed by patchadd and part of code responsible for this was completely redeveloped (by me) for Solaris10 to support patching over zones. It also introduce real multypatching, when patchadd does not require patches to be specified in dependency order as well as patchadd can take all patches from directory. Another side effect was significant speed up of patch dependency check - more then 100 times faster. Now if you try to install SUNWwebserver pkgadd will tell you that SUNWnetworking is needed or it may be not only SUNWnetworking but also SUNWsomepackage1, SUNWsomepackage2 and SUNWsomepackage3. When you try to install those package you may find out that they also require some other packages etc. It is really painful and time consuming to discover all this dependency tree manually. And there are no any reason why same discovery can not be done by pkgadd or patchadd itself. Simple recursive algorithm can parse down dependency tree and find all necessary packages, no big deal. Same for patches. Before when all dependency for patches were checked by ksh-script using awk, grep etc... it was really hard to do dependency tree analysis, but now with new C-code and C-data representation it is easy to do. What patchadd and package add need for this analysis? They both need information about dependency which exists in package and patch metadata. Information about all required packages or patches should be available. Patchadd and package add already have notion of "directory" (-M and -d options), so we already have some idea of "installation base" where all patches or packages are located. This is the place from which patchadd and pkgadd will take all dependency data to discover all required packages or patches. So now when patchadd discover that requested to install patch require some other patch which does not present on the system, instead of exiting with error code it will check "installation base" - directory specified by -M option, if that required patch is there. If it is there patchadd will check dependency for it same way and so on - this is why this patching called recursive patching. This is simplified explanation because required patch may not be in the patch directory, but it may be higher revision of this patch - which is OK, as well as it may be patch which obsoletes required patch - which is also OK.It very well may be that patchadd will pick up patch with different name then one which was initially required, but legitimate substitution of it. So recursive patchadd will pick the latest patch to install. I hope this helps. I will continue this later and will explain how it will work over http: - which is bit different then when "installation base" is in directory. vassun. This message posted from opensolaris.org
