Subject: Re: CVS commit: pkgsrc/pkgtools/pkg_install/files/admin
To: None <>
From: Greg Troxel <>
List: tech-pkg
Date: 08/10/2007 19:21:52
Joerg Sonnenberger <> writes:

> On Fri, Aug 10, 2007 at 06:49:45PM -0400, Greg Troxel wrote:
>> Joerg Sonnenberger <> writes:
>> > On Fri, Aug 10, 2007 at 10:39:14PM +0000, Greg Troxel wrote:
>> >> Log Message:
>> >> Reword description of rebuild-tree, and point to pkg_delete -f as a
>> >> possible cause of inconsistencies. Remove comment about make replace,
>> >> since it does not, absent pkgsrc/mk bugs, result in incorrect
>> >> dependency records.
>> >
>> > I'm not sure. If it creates a conflict, that might actually happen for
>> > make replace.
>> Hmm.  I haven't seen it.  What make replace does is save the
>> +REQUIRED_BY, remove the package, put the new package in place, and then
>> +restore +REQUIRED_BY, and then patch up every depending package to
>> +point to the new place.  I'm not sure wha you mean by conflict - I can
>> +believe, on reflection, that a failed make replace can leave things
>> +inconsistent.  I just didn't want to give the incorrect impression that
>> +normal make replace messes up +REQUIRED_BY files.
> The patch-up part is IMO completely bogus. It should die together with
> the exact match logic in pkg_add. I plan to remove that next.

The nature of make replace is that anything that depended on the old
package is modified to depend on the new package.  This is a safe
transformation if there isn't an ABI change, and it's dangerous if there
is.  The unsafe_depends tag enable pkg_rolling-replace to resolve the
dangerous situations.

While make replace isn't safe, there are only two other ways I know of
to update from source, and they each have problems:

  make update: preserves safety properties, but removes large amounts of
  packages before rebuilding them, leaving the system temporarily in an
  unusable state.

  pkg_comp: rebuild everything in a chroot, and then pkg_chk -r and
  pkg_chk add back.  This is pretty safe, but awkward.

So given that I think it's reasonable for people to use make replace,
both occasinally on particular packages, and as part of
pkg_rolling-replace, it ought to work as well as it can.  Right now I
think it's in good shape.

Can you explain what you mean by 'completely bogus', and what should be
done differently, assuming the fundamental idea of make replace is to

If you simply think make replace is too unsafe to use, that's fine - but
that's not a universally held opinion.