Re: make replace

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Wed, Jul 14, 2010 at 10:24:54AM -0400, Greg Troxel wrote:
 > > I've suggested a couple times that we might want to distinguish
 > > maybe-broken ("unsafe") depends, like gimp after replacing png, and
 > > definitely-broken depends, like perl modules after replacing perl 5.10
 > > with 5.12. Whether there are enough cases where we can tell in advance
 > > when a package will break to make this worth supporting, I dunno.
 > 
 > That would probably be a useful improvement.  One could then replace all
 > packages with known-broken dependencies first.

Right. I do that now with my update scheme, but it involves manual
sorting of the build tree, which is ... I wouldn't call it a hassle
because it's sort of akin to playing tetris, but it's not a good use
of time.

 > Right now we have unsafe_depends, when a dependency has been changed out
 > and it might not be ok, and unsafe_depends_strict, which is set when a
 > dependency has been changed out but we are sure that it's ok.  The point
 > of _strict is that sometimes things that are known to be true aren't.

Right.

 > Currently replacing a package with the very same version sets
 > unsafe_depends_strict but not unsafe_depends.

That seems unnecessary, though.

 > As we get better metadata about ABI versions and can describe "manifest
 > data says ABI changed" and "manifest data says ABI didn't change" we can
 > either split unsafe_depends into two or use _strict for "manifest data
 > says ABI didn't change".  I am skeptical of our ability to have 100%
 > accuracy on ABI changes, just from the sheer scale of things, so I would
 > favor a third variable.

So would I, I think.

 > > A definitely-broken depends notation might be useful after doing
 > > pkg_delete -f png with gimp installed, too.
 > 
 > Agreed; it would be nice if pkg_delete marked dependencies
 > unsafe_depends on pkg_delete -f, and also if pkg_admin rebuild-tree did
 > so when it doesn't find dependenices.

Yeah, I'm surprised it doesn't already do that.

My build scheme goes through checking if package1/+BUILD_INFO is newer
than package2/+BUILD_INFO, which in the absence of clock shenanigans
is pretty much guaranteed to return a superset of everything that
really does require rebuilding. I wrote that logic before
unsafe_depends existed (I think) but I haven't gotten rid of it
because sometimes one does need to do pkg_delete -f on things and
recover afterwards.

-- 
David A. Holland
dholland%netbsd.org@localhost