Geert Hendrickx wrote:
> Your solution looks a lot like FreeBSD's portupgrade, or Gentoo's
> emerge.  While these may be pretty damn handy tools, they still have
> disadvantages.  Even with smart dependency-ordering, the running system
> may be unstable/ unusable during the update.  And when a build fails and
> the old package is restored in place, you could suffer from binary
> incompatibilities if some dependendancies have already been upgraded.  

I'm not too familiar with pkgsrc (pretty new user), and this is kind of a rant 
about how pkg_chk ought to be portupgrade, so feel free to ignore it. For those 
not familiar with portupgrade however, it could be a worthy read to see if some 
of it can be picked up and used in pkg_chk, and I do feel it's relevant 
according to the subject.

I've been using portupgrade for 5 years on a running system without _any_ 
problems, so your worries about binary incompatibilities seems unwarranted. And 
the only unstable part is the few minutes it takes it to remove the old port and 
install the new, but that's the same as with removing an old binary package and 
installing a new one.

In order to explain what I miss from pkg_chk that portupgrade has, let me lay 
out how portupgrade works, in rough steps:

1. Establish the port's dependencies.
2. Install any missing dependencies or upgrade out of date ones.
3. Build the port.
4. Back up the old version.
5. Uninstall the old version.
6. Install the new version.
7. If installation failed, restore the backup, if not, delete it.

In step 5, it removes _only_ the port being upgraded, not it's dependencies. And 
in step 6 it installs _only_ the updated version of the port in question. I 
guess this is were you're worried about binary incompatibilities, but as I said, 
it has never been a problem.

A port's dependencies are established and checked at the beginning of the 
process. So, for instance, if port A and port B requires port C, then the first 
of A and B to be upgraded will make sure that port C is up to date, building it 
if necessary, and the other will see that when it is upgraded. If upgrading port 
C fails, neither A nor B will be upgraded either. This is, from what I 
understand, the functionality the original poster is looking for.

What I personally feel pkg_chk is doing wrong is that it starts with 
portupgrade's step 5 and uninstalls things, and not only the package being 
updated, but all of its dependencies as well. And it does this without 
portupgrade's backup functionality, so it can't restore my system if the upgrade 
fails either. There's unstable for you, especially when this is done live and 
not on a separate build system.

For instance, I have installed GCC 3.4 from pkgsrc on Solaris 10 and that's the 
only compiler installed (removed GCC 3.3 installed from SunFreeware that was 
used to bootstrap it). When I run pkg_chk and it wants to upgrade, lets say, 
GMP, it _starts_ by uninstalling the compiler. Needless to say, it can of course 
not build anything without it. Not only does the upgrade fail, but it leaves me 
with no way of restoring the system without going back to scratch (i.e. install 
GCC 3.3 from SunFreeware, rebuild 3.4 and all dependencies), which takes about 
two days.


- IT