Re: make replace

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Tue, Jul 06, 2010 at 02:20:57AM +0200, Joerg Sonnenberger wrote:
> On Mon, Jul 05, 2010 at 03:23:42PM +0200, Dieter Baron wrote:
> >   The fundamental assumption of make replace and rolling replace is,
> > that temporary inconsistencies in the installed package tree are okay:
> > The user knows what he's doing, the problematic parts of the tree are
> > marked and there is a (semi)automated way to repair the tree.
> 
> Is it so? I tried finding some discussion on the goals at the time of
> Al's original commit of make replace (rev 1.939 of mk/bsd.pkg.mk in
> March 2002), but I can't find any. So at least for "make replace" I do
> not agree that it is the goal of the target and my reading of the
> description of the target in pkgsrc.txt make it more sound like "it
> should work better".

Maybe you could have asked Al, and he'd have told you that the reason
behind "make replace" was to do an in-place replacement of the package,
with a fixup of all references to it.  Nothing more, nothing less.

We haven't had any problems with "temporary inconsistencies" until
now.  I'm still not sure why they're a problem, except maybe the use
of a binary database (unfortunately not transactional!) to hold
version information.

> >   I hope we all agree that creating inconsistencies unknowingly and
> > without warnings (and markings) from the tools should not be allowed
> > by the tools.
> 
> Yes.

Tools are meant to do work for someone, not tell you how to work.

So, no, I don't agree that I should drive three sides of a square
because my car can't turn left.

Sounds to me like the tools are inadequate and should be fixed, rather
than forcing everyone to drive the extra mile.
 
> >   So, as the tools are improved to catch more and more cases that lead
> > to inconsistent trees, make replace will run into more and more
> > problems.
> 
> Yes.

Not necessarily - first you need to fix the underlying problems in the
new, updated and renovated tools.

Regards,
Alistair