Hi, Bart Smaalders pÃÅ¡e v st 05. 03. 2008 v 09:02 -0800: > 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.
I don't agree. I met several critical patches which were touching 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)? > > No comments? > > 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? > 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. 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. > It certainly doesn't work across Solaris 10 updates. > But we are speaking about patches, not about upgrades. > >>>> 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. > Yes. The most of patches. Not all. It seems you didn't investigated the scripts you complained about. Why do you think I mentioned just pam.conf, httpd.conf or sendmail config files? These were "touched" in patches in history. > 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. > 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. Best regards, Milan
_______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
