[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: make replace
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
> 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.
> 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
David A. Holland
Main Index |
Thread Index |