Milan Jurik wrote: > > I don't agree. I met several critical patches which were touching > editable files. >
Then I suggest the reverting to a previous environment to effect backout is the right answer. Having patches backout themselves is not sustainable. >>>>>> zfs rollback is intended to immediately recover from the failed >>>>>> installation/ >>>>>> updating of packages to the currently live image. Any update that >>>>>> requires >>>>>> a reboot will always be done to an snapshot & clone of the current >>>>>> system, >>>>>> so no special handling is required to handle failiure. >>>>>> >>>>> Like live upgrade/patching today, but in quicker way. This should be >>>>> docummented very well, including impacts on local installations, to >>>>> avoid data loss. Also processes like SQL engines should count with >>>>> possibility that their storage can be affected by this rollback, even if >>>>> they will not be upgraded by IPS at that point. >>>>> >>>>> Any way, please, in ARC materials don't mix patch backout and ZFS >>>>> rollback, they are different parts of packaging. >>>>> >>>> I don't agree. We're working on changing file system layouts to separate >>>> user data from system binaries. Having a _working rollback that doesn't >>>> rely on hundreds of well-crafted patch backout scripts will be a huge >>>> improvement. >>> OK, it looks like I should give you examples: >>> >>> 1) software not managed by IPS - they will use standard filesystem >>> hierarchy. How do you want to manage /opt and /etc/opt and /var/opt (and >>> in this case I'm speaking about software which will use just these >>> directories which will be used also by packages managed by IPS)? >>> > > No comments? I'm still mulling over what to do about SVR4 packages that install bits into the same places that IPS does. Since everything gets rolled back at once, this may cause some confusion, but you're just going back in time. If you want to backout a patch (actually package version bump), go back to the point in time when you applied it, or install the older version. If the undesirable version edited config files, you'll need to go back it time. The new packaging system allows you to revert to previous states. It does not allow you to transition backwards into previously unvisited states. > >>> 2) well-known (read as stable interface) editable files in /etc (e.g. >>> pam.conf, httpd.conf, /etc/mail) - those hundreds of well-crafted patch >>> backout scripts are dealing exactly with this files >>> >>> 3) after some patches their data files are changed and previous binaries >>> don't understand new file formats at all - other hundreds of >>> well-crafted patch backout scripts are dealing exactly with this scripts >>> >>> You cannot just rollback some parts, you need to rollback everything >>> (except home directories). But then you will rollback even changes made >>> by admins or data from different storages. And even worse - unrelevant >>> to backouted fixes. >>> >> This sometimes works today, if everyone did everything correctly. >> > > What do you mean by today? IPS or SVR4? Svr4. See above. Say I install new version of package... start using new features in various places,etc. I now try to backout upgrade... how does this work? There is no difference between patch and package upgrade; they use the same mechanisms. > >> If I add a patch that updates a editable file version, now make >> administrative >> changes using the new format, and now backout the patch, what happens? >> > > As the patch must be backoutable (yes, we have few exceptions in Solaris > 10 updates, but those are not bugfixes), in several patches the changes > are removed/transfered back. > > But it seems you mixed two things (points 2) and 3) ). Editable files > usually don't change format, they are stable interface in the most > cases. So /etc/vfstab hasn't gained any new options? > Application data storage can change format (e.g. very simple is > in last years to allow "large file"). > > If editable files are touched by admin and patch then patch backout is > doing its best to remove changes. If it is not possible, it warns admin > and ask him for review of changes. Double patch backouts are tested by > Sun. > Carefully handcoded, hand tested by skilled patch artisans. Workable if I'm shipping 10 patches a week. Impossible if I'm shipping Nevada level change on an on-going basis every two weeks. >> It certainly doesn't work across Solaris 10 updates. >> > > But we are speaking about patches, not about upgrades. > But there is no difference between in the two in concept. Note that Solaris 10 updates are all delivered as patches. Solaris 11 will always be delivered as packaging changes; IPS revs package versions on every change. > You are just counting with the most of cases. Not all. So, to summarize > my complains against zfs rollback as patch backout > > - it will touch changes unrelevant to backouted fixes, but not in > consistent way. > > - complex software will need to be designed to count with IPS or > package maintainer will need to do important changes which haven't be > accepted by upstream. > > SVR4 patching problems are mostly based on Sun projects which didn't > count with patching in their designs. But scripts allowed to workaround > their problems. > > The second thing can be handled. The first can be more chanllenging for > admins. Since developers will be testing their changes using exactly the same system that customers use to install them, the problems w/ projects not considering patching will go away. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
