As requested, my comments on this design note. As mentioned by another poster regarding the series of emails you've posted about this feature, a document posted onto opensolaris.org would be preferred.
Vasiliy wrote: > 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. > You should provide a diff-marked man page for the above. You'll need it for the ARC fast-track, anyway. What does the manifest file look like? How does the user create it? What is the difference between the "pick latest" vs. the "pick closest" policy; perhaps you could provide an example? Why is "pick closest" the correct default? > 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. Is the above describing the current behavior, the behavior after this project is implemented, or perhaps both? I couldn't quite tell. > 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. > Where is this transactional mechanism - internal to patchadd, or someplace else? > 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. > So we need a modification to pkgadd? A diff-marked man page for that is needed, as well. I think an example of what the actual manifest file contents would look like is appropriate, too. Why would the user expect to use pkgadd for creating a patch manifest rather than one of the other packaging tools or a patch-type command? Is there a provision here for locating patches from multiple locations? It appears that patchadd only allows a single "-M" option. I'm not necessarily arguing that it should use multiple locations, but would like this clarified one way or the other. How are failures handled - does it back out all of the applied patches? Is there a need for patchrm to be able to remove an entire set of patches that were applied in this way? How is this going to relate to other tools such as smpatch and UCE? Will they be able to leverage this functionality? Dave
