"Next night. Dunyazad said: 'Sister, I pray you finish your tale.' To this Shahrazad answered: 'Gladly and with all my heart!' Then she continued:" The book of thousand and one night. by Powys Mathers
[b]Patch dependencies[/b] To talk about patch dependency check we need to know what are this dependencies. There are three type of relations between patches: 1. Parent-Child or Inheritance relation. This relation reflect current accumulation practice when patch accumulate all changes in certain software - part of Solaris. So if customer need latest changes - all of them are located in one single patch, latest revision of this patch. To support this new changes in specific area go to the next revision of existing patch which covers that area and which has all previous changes already. This relation expressed in two ways: 1.1. Indirect inheritance - revisions. Higher revision of patch inherits (accumulates) all previous revisions. Revision number is part of patch ID which is <PATHC_NUMBER>-<PATCH_REVISION>. For example 111111-02 is second revision of patch 111111. When some bug fixed - to deliver this changes to customer RE add this changes to existing patch and increment its revision (it may be several fix in one new revision it is up to RE). 1.2. Direct Inheritance. Usually patches cover different non related areas of Solaris, however sometimes fix may goes simultaneously to several areas. Current practice is - in this case to merge one patch to another. The one which absorbs another patch declares it as obsoleted - it is effectively next revision of obsoleted patch, inheriting it, but now it has different patch number. To express this there is special key in patch record - OBSOLETES <PATCH_ID>. This mean that no more revisions will be for <PATCH_ID> and it is now different patch number - one which has this record. It kind of complicate things, because for next revision we know how patch_id will look like - same patch number and bigger revision number, but for this direct inheritance there is no way to guess which patch obsoletes this one. 2. Require relation. Some change delivered by patch may require different changes which already previously introduced and already delivered by different patch. For example it may be change in utility which depends on certain change in libraries. This changes are related but it is not one change affecting different areas - what we have in case of merging patches, but two different changes from different areas but one depends on other. To express this relation there is key in patch record - "REQUIRE <PATCH_ID>". In terms of inheritance this means that Patch A and all its ancestors require patch B or any of its ancestors to be on the system. But patch B is not require patch A. 3. Incompatible relation. In some cases change may be incompatible with other change meaning that they may not be present on the system both together. To indicate this relation there is key in patch record "INCOMPATIBLE <PATCH_ID>". If patch A declare patch B incompatible this mean that 3.1. A can not be deployed on the this system where B or any ancestor of B is present. 3.2. Also B and any ancestor of B ma not be installed on the system it A is present there. 3.3. However B and any ancestor may be deployed on the system which has any ancestor of A, but not A. Incompatible declaration is not inherited by ancestors. This reverse incompatibility - 3.2. complicates dependency check a lot! It is real pain, just to understand it. There is no direct declaration for patch which obsoletes patch B that it is reverse incompatible with patch A! I end up with special tree optimization algorithm which set all the reverse incompatibility links right - will talk about this later... Example of using incompatibility relation I know only one. For emergency patches which delivers fast relief to the customer RE creates special revision of existing patch (or IDR) and make it incompatible with next revision of same patch. This force customer to remove emergency patch from the system before applying next revision. This does not play well with concept of accumulation on my opinion. Well, this is only example from real life I know so far. vassun This message posted from opensolaris.org
