>From my point of view two examples of dependency from previous post is just
>example of same relation between changes.
However in real life this two cases treated differently.
Example 1.
For first case when there is no intersection between two changes
{A', B', C'}
{D'. E', F'}
two current Solaris patches will be created
patch 111111-01 contains {A', B', C'}
patch 222222-01 contains {D'. E', F'}
and this kind of dependency is specified by REQUIRE field and it is directly
stated in pkginfo file (for each deltapackage) in patch 222222-01:
SUNW_REQUIRES=111111-01
For the second case if change includes file from previous change:
Example 2.
{A', B', C'} and {C'', D', E'}
Instead of have two patches with dependency specified patch for first change
will be revisioned:
111111-01 contains {A', B', C'}
111111-02 contains {A', B', C'', D', E'}
This is called accumulation for Solaris patches and this is biggest patch
problem Solaris has.
Why?
1. Patches grows up in result absorbing more and more files.
2. Patch configuration scripts hard to maintain because they should accumulate
all previous revision scripts.
3. Independent patch lines tend to merge to each other.
Example 3.
We have
patch 111111-01 contains {A', B', C'}
patch 222222-01 contains {D', E', F'}
new cage is {C'', D''}
for this case we are creating new revision
patch 111111-02 contains {A', B', C'', D'', E', F'}
Also in 111111-02 descriptor we define
SUNW_OBSOLETES=222222-01
This usually happens many times and in result we will have huge unmaintainable
patch which includes all possible change lines - nightmare to support on RE
side and deal with on customer side.
Another problem is that if for some area we fixing bugs let say once a month
issuing patch for it once a month, and in another area also once a month, then
when they merge we will have twice a month to issue patch or if 10 patch lines
merged together then 10 times a month! And regular developer can not do this
because changes from different areas are involved - it require special expert
to maintaining such a complicated patch.
So defining this relation with REQUIRE notation look much prettier. For Example
2 we will have
Example 4.
patch 111111-01 contains {A', B', C'}
patch 222222-01 contains {C'', D'. E'}
and descriptor in 222222-01:
SUNW_REQUIRES=111111-01
which is absolutely same what we have in Example 1.
For Example 3 we will have
Example 5.
patch 111111-01 contains {A', B', C'}
patch 222222-01 contains {D', E', F'}
new cage is {C'', D''}
for this case we are creating new patch
patch 333333-01 contains {C'', D''}
with descriptors:
SUNW_REQUIRES=111111-01
SUNW_REQUIRES=222222-01
This way all patches represents only one change and much more manageable in
result on both developers and customer sites. In this case however we will have
more small patches and much more advanced dependency tree - which is not big
deal to handle while we have new C-code for it in Solaris 10FCS. And recursive
patching is what need to be provided to handle this bigger dependancy tree as
well as big number of small patches.
vassun
This message posted from opensolaris.org
