Joerg Sonnenberger <joerg%britannica.bec.de@localhost> writes: > On Thu, Jul 08, 2010 at 09:58:09AM -0400, Greg Troxel wrote: >> 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. > > You are basically saying "whatever the dependency currently is, it is > wrong". I already gave examples for why that reasoning is wrong. If you No, I didn't say that. > don't care about consistency checks, don't use the destdir case and you > get all the lovely old consistency checks back. Wait a moment, there are > effectively none. You are turning "make replace should not fail when a manifest dependency is not satisifed" into "don't care about consistency checks in general". That's misrepresenting what people are saying - please stop that. The current discussion about restoring historical make replace semantics is because many people, when using make replace/pkg_rr, want 99% of the checks that the tools now do. destdir mode is not optional. It's the default for PKG_DEVELOPER, people have been asked to make new packages and updates destdir-clean, and people get pinged about packages that aren't destdir-clean. So telling people not to use destdir mode is unreasonable. > What you are consistently ignoring is that pkg_rr is not able to > automatically handle any of the cases where the single-package-replace > approach does not work. If it would handle that case, we wouldn't have > to have this discussion. I am not ignoring it. I've said repeatedly that it works sufficiently often that it's a rational choice. >> 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. > > I don't get why osabi has to be an exact dependency, that generally > doesn't make sense. Both the dependency and former recording as > buildinfo are very bad cludges as best. osabi is not that important in this discussion; it's merely what caused me to notice that make replace does not behave as it has historically behaved. > The whole notation of "unsafe" dependencies boils down to either the > tool just want to ignore what the package manifest says OR we are back > to the issue of open-ended library dependencies. recording unsafe_depends is a mechanism to resolve all the issues that get introduced. >> 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? > > It is a huge step backwards from actually making incremental updates > safe. I'm not sure what "safe incremental updates" will look like in your view (not trying to be critical - it's very hard). But changing make replace so that it doesn't work as it used to to get there isn't ok, because it breaks the way many people do updates now. Adding a fourth update method that meets your idea of safe/incremental would be great, and I don't think there would be any objections at all from the make replace crowd.
Attachment:
pgpYHJeiVRlY4.pgp
Description: PGP signature