Re: make replace

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

On Sun, Jul 11, 2010 at 09:51:26PM +0200, Dieter Baron wrote:
 > > You and/or Joerg appear to have conceived the idea that the existence
 > > of an installed package whose installation requirements are no longer
 > > met somehow constitutes an inconsistency in the package database
 > > itself. However, this is not true.
 > 
 > But it is: the consistency constraint that a package's
 > dependencies are satisfied is violated.  Agreed, it is quite a
 > different kind of inconsistency than e.g. dangling dependency
 > pointers or a corrupted database.

Yes, that's the point, it's not a package database inconsistency, it's
an inconsistency in the packages themselves.

Anyhow, it isn't possible to do an incremental update without
temporarily causing such states.

 > The point of my mail was, which invariants that are maintained by
 > pkg_add/pkg_delete without special flags (like -u, -f) need to be
 > lifted for make replace/pkg_rr to work.
 > 
 > So far I have: the dependencies need not be satisfied.  This is
 > marked with unsafe_depends.
 > 
 > Any others?

Nobody's offered any, and I doubt there are any, because it's about
package-level consistency and depends are the only way installed
packages interact with one another as far as the database knows or
cares about.

(I wouldn't describe this as an invariant that now needs to be lifted
though, as replace has been supported by the package database for a
long time.)

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.

A definitely-broken depends notation might be useful after doing
pkg_delete -f png with gimp installed, too.

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