tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: make replace

Dieter Baron <> 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

Home | Main Index | Thread Index | Old Index