Hi Dave,
I'm about to go off on vacation but here are a couple of initial comments
based on past experience and some recent customer issues we have ran into.
I'll frame them as requirements, and when I say upgrades below, I'm
thinking of the patches we have at present. Perhaps some of these belong
more with redesigning our packaging structure. Anwyay...
* Upgrades must not clobber a users configuration (I've some bugs open at
the moment for .conf files that are type f and are clobbered by
patches). - How do we address significant changes to
configuration files
without harassing the user? In particular for changes which we have
backported, the backport of Native LDAP 2 to Solaris 8 in 108993-18 despite
a lot of testing still managed to cause a lot of problems.
* Users should be able to select the minimum set of changes needed to
address their needs. (eg. to get a bugfix, users should not have to upgrade
to the latest features also. If you want to fix libc on s10x FCS you need
to upgrade to grub first.)
* How should reboots and service restarts be handled during an upgrade?
* re 2. ... graphical and _automate-able_ text environments.
* re 25 A user must be able to revert a particular distinct part of an
upgrade. (In current terms, user can apply patch A then B then C; but then
remove A provided there are no dependencies. The present language implies
reverting is a strictly sequential process).
* re 26. In addition to applying the software we need to ensure that it is
correctly patched, or at least show that it is not in whatever update tool
there is. In todays terms: If a user installs package A, then a patch X-01
which applies to packages A and B, patch installation will succeed. If the
user later installs package B, it appears that because patch X-01 is
installed that package B is up to date even though it is not - the user
needs to re-apply X-01.
* re 39. I'm all for speedup! The current situation with patching zones is
not good. However Solaris customers may wish to patch only every six months
say; this may require a slightly different focus than aiming for 'daily
upgrades'.
* The installation interface must allow the user to select a minimised
version of the distribution. In doing so it must automatically satisfy
requirements for what the user has selected.
* The ability to upgrade the installation media rather than post
installation on the system must be provided. Currently flash archives
provide this, but we do not provide any way for a user to freshbit patches
onto an jumpstart install image. The latter would be useful for adding
hardware support, in particular for x86 systems where the current boot disk
ITU process makes installation complicated, eg[1].
* Updates applicable to a minimised system must apply to a minimised
system. We come across patches in testing occasionally which should patch
the minimum solaris cluster, but require patches which only apply to say
SUNWCuser.
- Earlier on you mention that "Solaris user who are not developers are
few
and far between these days". I disagree, within Sun we have plenty of non
technical staff using desktops, or at least sunrays. Regardless, we should
provide a 'metacluster' which would be appropriate for a non devleoper end
user. Though I'd agree with the End User metacluster at present being
essentially meaningless; in fact I think that all metaclusters are fairly
meaningless.
Right, time to go to Turkey for an eclipse! I'm sure I'll have thought of
more to add by the time I get back!
Cheers,
~Albert
[1]
http://sunsolve.sun.com/search/document.do?assetkey=1-21-119376-02-1&searchclause=119376-02
--
Albert White - Patch System Test - Sun Ireland
albert.white at sun.com http://blogs.sun.com/albertw
