I was asked to provide design for Recursive patching (design review is major entertainment for many especially install design reviews and I just can not deny this, even by internal process it is not required for this small case).
Well, how it work I already told in so many words and everybody was able to run demo and see. 1. It is -D option which indicates that it is recursive patching. 2. In addition, due to Albert comment, we have also -L option which switch on "pick latest" policy and by default it works by "pick closest" policy. 3. To support recursive patching over http and https manifest file is required. How it is implemented. Relatively small changes. In normal case pdo parses information from /var/sadm/pkg/*/pkginfo files and then parse specified patches. If -M options used to define patch_base and no patches indicated in command line then it load all patches from patch_base, but if some patches are present in command line, then it will parse only those patches. Pdo load all patches from patch_base or only subset specified in command line and then applies recursive dependency check algorithm to all of them marking them applicable or not but it will check all requested patches. Recursive patching when both -M used and some patches specified in command line will parse entire patch_base and create internal data for all this patches. After this it apply recursive dependency check only to patches directly specified in command line. This way already existing algorithm will go over subtrees for this patches only and will not touch patches which are not involved. After dependency check for one patch I have subtree where all dependences are checked and all patches approved to be installed marked and sorted. This is exactly set of patches which I need to install and all dependency for root patch - one which was directly requested by customer using command line, will be satisfied. However if for some reason this patch failed all other patches which were marked as approved must be unmarked and for this I introduced simple transactional mechanism. Minor changes was introduced in distributed dependancy check over zones - not I had to pass to zones list of patches to check in addition to all represented in memory patches from patchbase. Albert had very good remark about how we pick patch which satisfies dependency if there are many of them - when different revsion of this patch are present. This is implemented by small switch wich indicate how check algorythm deals with inheritance and it is simple does not trace inheritance relation up in case of "pick closest" policy is in effect and do trace it up in case of "pick latest". For web patching I introduced additional parsing mechanism which parse manifest file. Patch records in manifest file is same as they are in /var/sadm/pkg/*/pkginfo with small addition - package information. This manifest is generated by pkgadd -m modification which output it for specified patchbase. This is not very big changes and this is all design I can think about. Other then this I can provide source code which will be not design review but code review (and code review is recuired by process). vassun This message posted from opensolaris.org
