Relation with packages.
Patch is directory which contain delta packages - packages which contain only
changed files (relatively to FCS - remember accumulation practice). If bug fix
affect some files A, B and C in package P and files D, E, F in package Q then
patch R for this bugfix will have deltapackage P with A, B, C in it and
deltapackage Q with D, E, F.
Directory structure will be like this:
./R
./R/P
./R/P/A ./R/P/B ./R/P/C
./R/Q
./R/P/D ./R/P/E ./R/P/F
This deltapackages will be installed using pkgadd to the system if there real
corresponding package are present (same time backout packages will be created
based on deltapackage contents to be able to remove patch). If package is not
present on the system deltapackage will be ignored (this is why new package can
not be delivered by patch).
Before pdo even start dependency check it looks is this patch applicable at
all, are there any packages which it updates on the system. Because if not then
there is no reason to do any check at all (this is why so called "Genesis"
patch did not work with pdo, because it install package in prepatch script and
then patch it with included deltapackage - pretty ugly on my opinion).
That example is only valid if there was no changes before to packages P an Q,
if there was some - then A, B, C, D, E, F will be added to existed in previous
revision of patch R or overwrite previous version of this files.
This mechanism however introduce big problem. Let say we have patch P with
deltapackages A and B. We apply P to the system which has only A initially and
it delivers changes to A, then after patching system with P we install package
B. Now package A has changes and package B does not! This is bad situation
fortunately pretty rare, and even if this happen it does not always cause
problems, but potentially it make system inconsistent. To resolve this problem
patch P should be reapplied and it will deliver changes to B only and will not
touch A.
This situation called - partially installed patch. Pdo detecting partially
installed patches - when patch, which already applied to the system, has some
packages which need to be updated. If such patch is detected it goes first and
no reason to check dependency, because it is already on the system.
Other way how partially installed patch may be introduced - by installing
freshbitted package. Packages from Update Release media already contain all
changes and contain also records about patches which delivers this changes -
after they are installed it looks like they were patched to this state from
FCS. This is necessary to keep dependencies in tact and not to break existing
patch lines, so patch revisions will be continued between update releases
without interruptions independent from upgrades between update releases
(between S10FCS, S10U1, S10U2...). In general customer may upgrade between
update releases as well as bring system to the same level by patching it with
recommended patch cluster or keep system at FCS level and just deploy only
critical for this customer fixes (I think we should allow this choice to patch
between major release, and it may be possible in theory). Some customers need
to test for several months new bits before letting them go into production and
so they are pretty sensitive to apply many changes to different parts of the
Solaris however other customers just go with recommended cluster every 3 months
or something.
This patches which are kind of preached already called freshbitted packages. If
they installed during Solaris upgrade, then all of them will be redelivered and
so all packages involved in one or other patch will be on the system. However,
if it is only one package from update release is installed on FCS system it may
right away introduce several partially installed patches. Let say package P
preached by patches A and B and A with package P also patches package Q and B
also patches package R - if Q and R are on the system then right away it will
be two partially installed patches and so two potential system inconsistency.
More then this - if patch A for example is incompatible with patch C which is
on the system or require patch D which is not on the system, then system will
be inconsistent for sure! Right now pkgadd does not check patch dependency at
all when installing freshbitted packages. Sounds like scary tale... However
this is more theoretical situation, rare in real life and easy to fix
redelivering related patches. Right policy to avoid this problem - install only
FCS packages and then patch them to current patch level. But I will resolve
this problem with recursive packaging project where I like to recursively
install not only packages which requested one depends on but also all related
patches - preached patches plus all they depends on.
And of course inheritance complicates this partially installed problem (as it
complicate everything else). For example patch P updates packages A and B,
package A is patched by patch Q which obsolete patch P, but B is not patched by
Q and if we repatching system with P we better bring changes to B to at least
decrease inconsistency if not eliminate.
Package as an container for patch information.
All information about patch relations are located in patch records. This record
present in pkginfo files. Inside patch itself this data present in each pkginfo
file in each deltapackage.
Example:
After patch installed on the system this patch records will be included in
current pkginfo file to each package.
Example:
As you may see there is no any information here about contents of the patch in
terms of deltapackages. Patch itself contains all deltapackages as a
subdirectories but after it is installed this information is not available any
more. This prevents us from detecting partially installed patches when
installing FCS packages - even patch P is on the system we do not know that it
is applicable to package that we are installing right now, so no way to warn or
detect this situation without patch body being present. Same for freshbitted
packages - we have dependency information for preinstalled patches but have no
idea which packages this patches affects also, so no way to detect and warn
customer about partial installed patches introduced this way until this
information is present (which now available only in patch body).
Resolution of this will be expanding existing pkginfo records to include
package information also. I think that creating special registry or something
for patches will be bad idea, because it will overcomplicate upgrade between
update releases which will need to maintain this registry as well as dealing
with freshbitted packages. Simple addition to patch record as additional key -
PACKAGES will do the job easy and elegant. I am not big fan of sticking
relational databases to everything everywhere without good reason.
>From pdo point of view - there is two sources of patch information
1. Patch body - full information.
1.1. Pkginfo files in deltapackages.
1.2. Directory structure.
2. Installed Package
Patch records in pkginfo files in /var/sadm/pkg/*
To determine partially installed patch pdo checks pkginfo files and detects
there that patch is applied to certain packages. Then it checks patch directory
structure and compare set of deltapackages with what is on the system, if some
deltapackages are present on the system and do not have record about this patch
- then we have partially installed patch.
And in addition pdo also check architecture, OsRelease and ... of current patch
before patching.
vassun
This message posted from opensolaris.org
