Hi, Bart Smaalders pÃÅ¡e v út 04. 03. 2008 v 10:01 -0800: > Milan Jurik wrote: > > > Thank you for your answer. It looks much better (If I remember well > > there is some possibility to "freeze" updates in IPS). In several cases > > it will require some special "undo" patch update (to remove bits unknown > > to main repository, IDR can be very different from the final fix), but > > it is doable. Good for support. > > > I think you may misunderstand how this works. > > The client knows what's installed locally; it has the current manifests. > When installing updated versions of existing packages, the _client_ > computes the necessary transformation to convert the existing > software load into the desired one by comparing manifests. There > is no need for a single repo to know of all packages or all versions. > > There are requirements about the same file not existing in two packages, > etc. > The more disconnected package names, etc, of course, the more > difficult this is, but for maintenance level changes this will not be an > issue; > most patches don't even introduce new binary files, let alone change > package names, etc. >
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. > >> 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. > > >> 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? Best regards, Milan
_______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
