Hi,
TJ Yang wrote:
I read albertw's blog but I failed to understand how to use Solaris'
patch management system to be a modern PMS for OpenSoalris.
I would advocate the use of patches for updating packages. But I would
be very >interested in seeing the things that people don't like about
patches and patch >management and what enhancements folks think should
be added.
To me a modern PMS need to have following features.
1. support software build
1.1 automate the process of software building.
This is something that I hope would be documented by the patch and package
utilities team when they get to opensourcing their tools. Maintaining a
software gate is a complex task and there is a lot of process to consider
as well as tools. However the process can be sufficiently automated to
allow an engineer to easily create a patch if needed (eg IDR's).
SVR4 patches and packages support the use of scripts withing patches and
packages to achieve certain behaviors. Specific editing of config files
being one example. Obviously if you are in a situation where you need to
write such scripts your process will require manual intervention.
1.2 auto build another application if depended by current one.
That is not so straight forward. For example a libc change does not require
you to redeliver everything even though pretty much everything depends on
it. Perhaps some patch creators or gatekeepers on the list can elaborate on
this.
2. support packaging(turn binaries,doc into a special format for installation).
Already provided by pkgmk(1). Our internal tools to create patches have not
been opened yet.
3. support application depot
a local or centralize server to accept and deploy packages.
Well at the simplest level you can put all your packages and patches onto
an NFS server and a cronjob to update. Or you can use the pkg-get approach
to deployment. For patches consider how smpatch and the Sun Update
Connection Manager do things. Using SVR4 packages and patches does not
force you into a particular "application depot" method, you are free to
choose whatever you wish for your opensolaris distribution. In fact by
using SVR4 patches and packages you will find it easier to leverage
existing higher level applications for your purposes (eg. your HPMS TWW
system).
Having said that there is room for RFE's to the package and patch utilities.
4. support application management activities.
4.1 install : better yet, support auto install if dependency appear.
pkgadd and patchadd handle install. patchadd in solaris 10 has the ability
to solve patch dependencies when give a list of patches so they are
installed in the right order (checking of SUNW_REQUIRES). pkg-get is an
example of how the architecture can be used to automatically install
dependencies.
4.2 remove: auto remove depended application if need to.
So if package or patch X requires Y, then when you go to remove Y, X is
also removed? This is an existing RFE I believe for pkgrm. smpatch does
this for patches (I think) and perhaps patchrm should have this ability also.
4.3 query : provide local installed application and aviable apps on apps
depot.
I don't understand your description here. Each system will have its own
record of what is installed (/var/sadm...). Based on this it would be
possible to query your 'depot' to look for changes and then choose to
install those changes. 'smpatch analyze' is a good example of this for
patches. 'pkg-get -c' is an example of how to achieve this with packages.
4.4 update: auto remove the existing app or insert the deltas.
This is similar to a combination of install and query. Once you have a
given set of packages and patches installed it is possible to determine
from a given list of patches which will install on the system ('smpatch
analyze' and 'patchadd -M <directory of patches>' for example).
Would you please advise me how Solaris patch management system support
above requirements ?
Your questions come in two flavors. Creation of patches/packages and higher
level package management.
Package creation is a documented process that is available at the moment.
Patch creation and patch utilities are yet to be opensourced. When they are
I expect that the process of creating patches will be documented, which
will address your concerns regarding automated building. Perhaps we will
see the process and tools for building packages in the build process first.
Your other points deal with features you would like in a management
framework. Some of these perhaps should be RFE's for the base utilities,
but most belong at a higher level.
What I was advocating in my blog posting was the use of packages and
patches, one reason being that existing technologies (zones) are built
around this architecture. You are free to rewrite the package mechanism if
you like and my blog highlights some of the problems involved with this.
For the reasons there I think it is in everyones best interest to use the
existing package architecture in opensolaris based distributions.
Any distribution that chooses this format will then automatically be able
to leverage the various higher level package management tools that have
been discussed here before to update their system.
If a consensus develops among the distributions to go with a particular
high level management system then thats great. But its a separate
discussion from whether to use the SVR4 package architecture.
Cheers,
~Al
--
Albert White - Patch System Test - SUN Ireland
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
