Opensolaris.org is go. Go register! Although I don’t write code for solaris I can share Bryan’s sentiments about it feeling like your hometown getting flooded by tourists. And wasn’t there a good job done of making the town nice for you all!
I work in patch testing, and over the past few years I have seen a lot of ‘interesting’ problems with updating products. As such I thought I would have my first opensolaris post be some food for thought regarding package/patch management.
Eric Boutilier has started some interesting discussion on how package management should be done with opensolaris.
Let me dive ahead and share some thoughts on supporting a distro you have made. This I would argue should be the basis of a package management discussion.
The options that Eric lists deal with packages. Pkg-get for example deals only with packages, if there is a bug in the application you are using and a new version is released you will get the entire package re-installed and the version number incremented. Where dependencies are concerned, if the new bugfixed package has a dependency on another package, for say a new feature it will be downloaded also, and so on. For what might be a fairly trivial bugfix you could end up needing to upgrade many packages. This was one of my personal annoyances with Debian.
Solaris package and patch management is different. All packages in a version of Solaris have the same version sting. If there is a bug, the package is rebuilt but only the differing files are distributed with the patch. If there are other requirements patches can depend on other patches which again only distribute the changes from the initial release. In some cases the patches need to merge with other patches to accomplish this correctly, and in other cases the requirement is not that strict at all and you will see note in the patch readme telling you to ‘get patch xxxxx-xx for the complete fix of Bug xxxxx’. There are many other cool things that can be done with patches, for example Interim Diagnostic Relief ; with this a special ‘patch’ is created by an engineer to give to customers to get more diagnostic information on a problem or to provide a test fix before the tpatch is made. Using this system the administrator cannot apply any patches to the affected package until the IDR has been removed. More importantly the information about this IDR is stored in the package database; so you never have the problem of not knowing whether any test binaries are left on the system.
The advantages of patches only comes into play once the OS is stable. For example each build of opensolaris will (I expect) have different version string for each package. At some point you decide to take the image that you will use as the base for your distribution. At this point your version strings should stay static for the lifetime of supporting your distribution. Once the opensolaris build continue more fixes and features will go in, so you may not be able to just grab the latest bits and hope they work with your distribution, you will need to take the code changes and merge them back into the version you made your stable release, and presumably tested all your other software against.
Once this is done you have a choice to make regarding patches or new packages. It is this decision that most thought should be devoted to.
Some other considerations that any alternative to patches need to address:
- How will they upgrade zones in open solaris?
- How will they support diskless client (if you support it)?
- What control will you give for the management of user editable files, for restarting services, for unexpected things that may need to be done before and after the service is restarted?
- How do you define what ‘level’ your system is at?
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.
As yet the patch utilities are not released in opensolaris, but nevertheless its something to think about.
Technorati Tag:
OpenSolaris
Technorati Tag:
Solaris