Re: Packaging Questions

[Peter Schuller <peter.schuller@xxxxxxxxxxxx>]

> 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 <peter.schuller@xxxxxxxxxxxx>'
Key retrieval: Send an E-Mail to getpgpkey@xxxxxxxxx
E-Mail: peter.schuller@xxxxxxxxxxxx Web: http://www.scode.org