[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: make replace
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
> > I hope we all agree that creating inconsistencies unknowingly and
> > without warnings (and markings) from the tools should not be allowed
> > by the tools.
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.
Not necessarily - first you need to fix the underlying problems in the
new, updated and renovated tools.
Main Index |
Thread Index |