On Tue, 24 Dec 2002, D'Arcy J.M. Cain wrote:

>     deinstall --> build --> install
>
> to
>     build --> deinstall --> install
>
> That way the system is never down except for the short time between the
> deinstall and the install.  This also helps the situation when, for whatever
> reason, a package doesn't build.  I just think that "make update" shouldn't
> involve so much praying.

One solution: You could build binary packages, all to a ${DESTDIR},
but then you have to build/install all prerequisites to ${DESTDIR},
too. That should work with all "imake" and "GNU configure" packages,
at least.

With "make update", the situation is hopeless. The thing is, you could
always do as you suggest with the root package, but as soon as you
recursively delete a root package and all its dependents, you're in
the same boat as before. If you could update in place, then you could
build before installing. What's more, the reason for "make update"
goes away -- since you don't have to delete the dependendents anymore,
you don't have to rebuild them if you don't want to...

I've worked out an inchoate system to do just that -- update in place:

  ftp://ftp.netbsd.org/pub/NetBSD/misc/fredb/pkg_hack.tar.gz

Once you figure out how to build and install it, all you have to do
is type "make install" or "make package" in the directory of the
package you want to update. It'll automatically update, in place, any
dependencies that are out of date, then build against the last
dependency installed (by virtue of the soname ".so" link).

Some known problems:

1) bsd.pkg.mk isn't very friendly about overriding the dependency
search targets, so to make that work, I've sacrificed just-in-time-su.
Therefore, you have to install as root.

2) With current, you need to install GNU tar, and set ${GTAR} in the
environment.

3) Once you've rebuilt something like "png", you're ultimately going
to have to rebuild all the intermediate dependencies (in any case).
The pain is only deferred. If you've forgotten that you updated a root
package with lots of dependencies, you're might be surprised, when you
go to update a "gnome" package, to see many packages being rebuilt.

4) If packages are updated in arbitrary order, the dependencies get
"fixed" to the installed version. This isn't a problem if you only use
the hack on your installed packages, but if you build binary packages
to share, you have to take care to re-build "from the bottom up".

Frederick