Re: make replace

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

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
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.

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.

> 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.

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.

> 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.

Joerg