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. >> 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. >> 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. > 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. - 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
