On Fri, Jan 23, 2004 at 02:20:12AM +0000, John Goerzen wrote:
> I've observed that "make update" runs pkg_delete -r, then builds the
> package, then re-installs the dependencies.
[snip]
>   1. Stop it from deleting things that depend on the package.
>      In this case, there is no reason that it needs to delete kde.
> 
>   2. Have it delete the package only after "make build" is complete.
>      There's no reason that Perl should have to be deinstalled before
>      it starts building the new one.  Let it build it first, then
>      deinstall it, then install the new.
[rearranged]
> It really seems this could be a lot less disruptive.  Maybe I'm missing
> something obvious?

You've raised a whole bunch of related but independent issues at once.

Firstly, the recursive deletion of dependencies. This is done for a very
good reason: if you update a package that provides shared libraries 
without rebuilding the dependencies, you will probably end up with
subtle ABI incompatibilities. This may not be a big deal for a single
user development machine, but is unacceptable in a production environment.

(If you feel lucky, and you really don't want to rebuild dependencies, you
can manually issue "make replace", but don't say we didn't warn you...)

Second, the idea of compiling and installing en masse has been floating
around for a while. A future replacement for pkg_chk will almost 
certainly do this. 

There is another, bigger, issue with pkg_chk's update feature that you
haven't discovered yet: on systems with deep depgraphs, it often ends
up rebuilding packages several times. This is a problem when pkg_chk
decides to rebuild Mozilla three times on a Pentium class machine ;-). 
Also, pkg_chk's handing of binary packages is incomplete.

I think it's fair to say there is a consensus that pkg_chk is broken
in it's capacity of updating packages. Various people have threatened
at various times to fix it, but nothing has happened yet. Look through
the tech-pkg archive for "pkg_chk" for the gory details.

> Even better: why even deinstall at all.  Why not install the new
> version, then delete any files/dirs that the old version provided that
> were not present in the new one?

Mmmmm... no. Deinstall/install takes a small fraction of the build time.
This would enormously convolute the reinstall code for a vanishingly
small benefit. It's also not clear how install/deinstall scripts and
@(un)?exec in PLISTs would be handled.
-- 
Bruce J.A. Nourish <bjan+public@bjan.net> http://bjan.freeshell.org