Here I like to talk multipatch dependency check which is not directly related to zones - generic dependency check, which is complicated enough even without zones.
Patch dependency check has three stages: Stage I Loading data from files - creation of datastructure. It is created during parsing files - like for single pass compiler. First I parse system current patch context from /var/sadm/pkg/*/pkginfo It parse one by one all pkginfo files from /var/sadm/pkg and creates both package and patches internal objects. It take first PATCH_LIST key in pkginfo which indicates what patches are effectively applied to it and then effectively each patch record and creates corresponding patch for patches which are listed in PATCH_LIST. For each patch from pkginfo record will be created patch object and marked as "System" - if it is already exists then information will be added to existed object. All related patches will be also created or updated if they already exist. So if there is required patch and it does not exist yet - I create "Virtual" patch which represents this relation only, but not real existing patch. Until I find it in some pkginfo file and parse its record - then it will be turned into "System" patch. Different pkginfo files may have records about same patch - so many times pdo parses same patch record, but this is the only way now to figure out relation between patch and package. All patches for package which pkginfo file pdo parsing will be linked to it and wise versa. In general on balanced system all patches which are required by some other patch should be non Virtual. However for incompatible patches - all of them must be virtual. This is not completely true, because of inheritance - patch may require lower revision of patch which is actually on the system, so it will be virtual but with System patch on top of inheritance path. For indirect inheritance support - revisions, I create recursively virtual patches for all lower revisions to 01. So if I parse patch 111111-15 then 14 "Virtual" patches from 111111-01 to 111111-14 will be created so if I will parse later 111111-08 it will be inserted in existed inheritance path and I will be able to trace from it to 111111-15. It is more important when I, later during dependency check, will trace relations - like some patch may require 111111-05, so using existed virtual 111111-05 I can easy find that 111111-08 as well as 111111-15 exist. Obsoletion complicates this even more - trust me direct representation of each revision in the tree is very handy. But in result I have many long revision threads where most patches are virtual. I am handling it later on stage II, when I will optimize tree and will remove all this virtual threads with simple tree optimization. When all pkginfo files parsed I have set of System patches, Virtual patches and System Packages. Patches and packages will have bidirectional links if they are related. This information is necessary to identify partially installed patches when I will parse requested to install patches. Then pdo parses requested to install patches - patches from some directory and specified in command line one way or another. Pdo parses similar pkginfo files which located inside patch subdirectories - delta-packages. For this records it creates patch if it is not exist and marks it as "Requested". If it is exist as a Virtual, which means that some other patch, which we processed before, refers to it - then it updates information in this record and marks it as "Requested" too. If it is exists and marked as "System" this mean that this patch already applied to the system before and pdo need to check is it partially installed or not. Now pdo can do this because it knows all packages affected by this patch and if some of them are not linked to this patch on previous stage then they are not updated by this patch (no record in that package pkginfo file) and we have "partial installation" - pdo marks this patch as "Partial", which means that we have to install it first and without dependency check - it is already on the system and we need to repair inconsistency (except it obsoleted by direct or indirect inheritance). All patches related to one we parsing will be handled same way as we doing for "System" patches - no difference. After this all data necessary for dependency check are loaded. It will be this types of patches in memory after Stage I. System patches - which already applied Requested patches - which customer ask to install Partial patches - which partially installed to the system Virtual patches - which were referenced by some other patch At that point I already filter out patches which are: 1. Already fully installed - all packages from this patch which present on the system up to this patch level. 2. Duplicates in requested to install list. vassun This message posted from opensolaris.org
