Milan Jurik wrote: > I think you missed point. Patches are not only about binary > deliverables. They are also changing editable files (and not all of them > can be pushed to SMF). And IDRs can do changes unknown for the rest of > patches (and sometimes they are doing it). But as I wrote in my previous > e-mail, this can be solved by some "undo" updates before merging with > main repository. >
Note that we're not accumulating change in a patch the way we do today; a bug fix (especially an IDR) is quite unlikely to require changes to editable files. >>>> 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)? > > 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. 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? It certainly doesn't work across Solaris 10 updates. >>>> Unlike today, IPS will not encourage the piecemeal upgrade/downgrade >>>> of portions of the operating system. >>>> >>> There is one aspect of patch backout I don't still see in IPS. If admins >>> will discover that some daemon started to core dump/memory leak after >>> several weeks with applied "patches", they will depend on repository >>> owner to release interim fix (which could be undo of previous fix), >>> won't they? After a week ZFS rollback can be dangerous in some cases. >>> >>> Today they can backout the possible offender and confirm part of >>> hypothesis. >>> >> It may well be possible to downgrade the package version, if the daemon >> exists in it's own package. >> > > Yes. In case that only binary changed, not parts I mentioned earlier. > Yes, even in rpm or deb packages you could try to downgrade (and start > to pray you didn't break something). > >>> Just small note - with patches today you have full control over patch >>> application/patch backout. In IPS "actions" could be designed as >>> backoutable, but it will be hard to push "postrun actions" to be >>> backoutable. >>> >> Actually, with some thought most post-install scripts in ON are >> completely reversible; certainly bug fixes will almost never need >> post-run actions. >> > > Really? Yes. Most bug fixes (not rolled up patch accumulations) affect one or two binaries, and no configurable files. Most editable files are a line-by-line merge of deliveries from separate packages. Note that if each package delivered it's portion of the common file into a separate file, and the smf service merged the various entries together when one had changed, uninstalling a package would simply require remerging the file again. - 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
