> Hmmmm. When this happens, and a big (meta)package cannot be upgraded > (gnome) due to a dependency failure, what state does this leave the > system in? Are the new packages already half installed? Or does it > wait for all packages to be built before upgrading?
Currently pkgmanager upgrades each package individually using 'make replace'. In other words, at no point in time is a package missing from the system except in a short window during the 'make replace' (which occurrs after building). A big meta package, like gnome, cannot fail per se due to a dependency; what happens is that the dependency that failed will be left alone and, because of the failed dependency, any package depending directly or indirectly on that package will not be upgraded. If the upgrade was major (let's say between incompatible versions of gnome), this means gnome will likely be broken until that particular package can be made to build (i.e., some basic gnome libraries might have been upgraded, but some of the higher-level applications that depend on those libraries through the package that failed, will not have been). In other words, given: A <--- B <--- C If B fails, this means A will have been upgraded first and succeeded (by definition, as a result of the order in which pkgmanager will perform upgrades), but C will not be upgraded. If the old (non-upgraded) version of B or C is not runtime-compatible with the new upgraded version of A, the application will no longer work. For most incremental upgrades however, this has not been an issue in practice. Since pkgmanager became finished enough to use, I have done incremental upgrades very often on at least a couple of machines, and so far I have not even noticed the upgrades (i.e., I have yet to encouter a case where something was noticably broken during the upgrade). In fact it has worked far better than I thought it would, inspite of a total lack of special handling of shared libraries or anything to ensure compatibility. Of course there is no guarantee. > Can pkgmanager handle binary upgrades? Not yet. I have plans to make pkgmanager support fully upgrading a 'mirror' of the system in a chroot. pkgmanager would then be able to do a relatively fast upgrade of the "real" system using binary packages produced in the chroot. Alternatively I have been considering having pkgmanager maintain two chroots. One that is "active" and one that is not. pkgmanager would then be able to bring the non-active chroot up to date and, when the user is satisfied everything is fine, be able to semi-atomically "switch" the two chroots - perhaps by having /usr/pkg be a nullfs mount of one of the chroots. There are issues with that however (such as differences in /etc that affect packages, causing mismatches between the chroots and the host system). > Basically what I'm worried about is ending up with a system that > has half the dependencies upgraded -- and being forced to downgrade > them all by hand to get things working again. Like I said there is no guarantee; but I can *definitely* say that statistically you will be a lot more safe with pkgmanager than with "pkg_chk -u" or similar. In my experience so far, pkgmanager has worked as well or better than what I am used to from portmanager/portupgrade with FreeBSD ports. In summary, if you can accept portmanager/portupgrade with FreeBSD, you should not have any trouble (relatively speaking) with pkgmanager. If you require real guarantees, then pkgmanager can not yet provide that but I hope it will in the future. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org