On Wednesday 25 December 2002 11:26, Frederick Bruckman wrote:
> On Wed, 25 Dec 2002, D'Arcy J.M. Cain wrote:
> > On Tuesday 24 December 2002 09:25, Thomas Klausner wrote:
> > > On Tue, Dec 24, 2002 at 08:29:24AM -0500, D'Arcy J.M. Cain wrote:
> > > >     deinstall --> build --> install
> > > >
> > > > to
> > > >     build --> deinstall --> install
> That's not really the obstacle. Even before buildlink, only a handful
> of packages were affected. What's more, if a package is broken in that
> way, anything you to with "make update" doesn't fix it -- plain "make"
> with the old package installed is still going to break, and people are
> still going to complain about that.

So don't change anything else in the process except what I suggest above.  
Let's look at it this way.  I have three packages, A, B and C.  A depends on 
B and B depends on C.  I update A.  Here is what happens now.

Remove A
Remove B
Remove C
Build C
Install C
Build B
Install B
Build A
Install A

Here is what I am proposing.

Build C (Note 1)
Remove C
Install C (Note 2)
Build B (Note 1)
Remove B
Install B
Build A
Remove A
Install A

Note 1: Doesn't depend on anything else so versions of other pkgs irrelevant.

Note 2: Worst case is that A and B fail to work now.  This is no worse than 
now where A, B and C are guaranteed not to work until everything is finished.  
At best the other packages still work while they are being rebuilt.

I just updated gdbm and it decided that kde needed to be built again because 
of a minor change to the package.  Now KDE is down again until it gets 
rebuilt.  Not so bad for me but my client (OK, wife) is down until later 
today as it takes hours even on a 1 GHz machine.

> > The worst case is that the dependent package gets built and
> > installed and the one you are building fails and leaves the old one
> > in the system.  That can't be any worse than losing the package
> > altogether and will often still work.
>
> If you're managing to do that, you're using some hack to install a
> package on top of the old one, like ${FORCE_PACKAGE_REGISTER}. The
> clear advantages of *my* hack over *that* hack are

Nope.  I actually do what I am proposing manually sometimes with simple 
dependencies by following the chain and building, deinstalling and 
reinstalling the end of the chain first and working my way back up.  Clearly 
not workable in the general case unless it is automated.

-- 
D'Arcy J.M. Cain <darcy@NetBSD.org>
http://www.NetBSD.org/