Subject: Re: Smarter make update / pkg_chk algo
To: None <email@example.com>
From: Idar Tollefsen <firstname.lastname@example.org>
Date: 05/04/2005 12:39:53
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