Dieter Baron <dillo%danbala.ifoer.tuwien.ac.at@localhost> writes: > What I am trying to figure out is which inconsistencies are needed > to accomodate pkg_rr. First, there are large classes of inconsistencies that I think we actually do have agreement are unwanted. The we-all-agree-is-bad list has things like: two packages of same name installed files in fs do not match database package A thinks it requires B, but registry of B does not show that A depends on it and arguably has all the consistency checks are on this list except for the one overridden with -D in my patch. The specific property that make replace has had for 4 years is if a package has had a dependency replaced out from under it, the variable unsafe_depends is set With this property, we have a consistency property: if a package does not have unsafe_depends set, then the dependencies in the datbase are actually the ones that would have been enforced All that the patch I posted does is add a flag so that make replace in the destdir case will function when there is an unsatisfied manifest dependency of a depending package. That depending package will still be marked unsafe_depends. Typically, people use pkg_rr to identify packages with unsafe_depends set and rebuild them (in the right order, so each package is only rebuilt once). With the new flag, make replace can stop using -f. I honestly do not understand why anyone who is concerned with consistency would think that's a bad thing -- with my change, the only inconsistency that arises is the "replaced dependency ==> unsafe_depends" one for packages with exact dependencies. As dholland points out, for those using make replace/pkg_rr, that's a) temporary and b) a different consistency rule that is very useful. So the whole discussion about allowing many other inconsistencies seems disconnected from reality. I'm not trying to have an argument that invariants are in general bad or anything like that - in general I like them very much. I'm only addressing the specific issue that the tools currently don't cleanly support the semantics of make replace, and have proposed what I consider to be a tiny change to support those semantics while maximizing the continued use of consistency checks. There's an important point about dependencies that has been missing from this discussion. There are manifest dependencies, encoded in the requires statements in packages, and then there are actual dependencies, which are the set of dependencies that actually work. Sometimes manifest dependencies are not satisfied but actual dependencies are (e.g., osabi-netbsd going from 5.1RC2 to 5.1RC3). Sometimes manifest dependencies are satisfied but actual dependencies are not (e.g., jpeg going fro 7 to 8, where the old depending packages had jpeg>=7 but the shlib major changed). So the notion that it's really bad to allow replacing a package that has an unsatisfied manifest dependency doesn't make sense - the far bigger problem is that manifest dependencies don't capture actual dependencies. So please let's bring this back to the point at hand: what specifically is wrong with adding -D and having destdir-mode make replace use it?
Attachment:
pgpPiqfryiO12.pgp
Description: PGP signature