--=-=-=
Content-Transfer-Encoding: quoted-printable


    I'm really sorry I didn't reply earlier (ENOTIME): While the change
  is fine, I don't like the name of the variable, as it does not make
  its meaning clear.  Could this be changed to dependency_replaced?

I'm not averse to changing the name; it's easy enough.  I didn't think
about the benefit of discussing the name - I was really only thinking
about whether there'd be any conceptual objections.  The only real
issue is ending up with variable turds, but those go away on upgrade
and thus will filter out.

The semantics are meant to be that a dependency has been replaced
_and_ that this operation is not known to be safe.    Right now
there's no way to know, but that's a separate issue.  Later, one could
for example know that going from 1.2.3nb4 to 1.2.3nb5 of something
really does preserve the ABI, and in that case it would make sense to
mark a package safe_dependency_replaced for the ultraparanoid, but not
trigger rebuilds normally.

My take on "unsafe_depends" is that it says that the way the package
depends on what it depends on is unsafe.


Do you have suggestions for variables, to mean:

  dependency replaced, not known to be safe (safe :=3D=3D same ABI)

  dependency replaced, recorded in control files as safe

  user/tool says this should be rebuilt (out of date, because they
  want to)


Currently I was thinking (having more than one was prompted by the
recent discussion):

  unsafe_depends
  safe_depends
  rebuild


So I suppose this could be

  unsafe_dependency_replaced
  safe_dependency_replaced
  rebuild_requested

=2D-=20
    Greg Troxel <gdt@ir.bbn.com>

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (NetBSD)

iD8DBQFEvM08+vesoDJhHiURApUYAJ0c3IsHRdN/mCu3RbVrn8ZpPq6cFgCgh9tn
N4HVkqceqjv08yBCz9JZNnw=
=Zfrx
-----END PGP SIGNATURE-----
--=-=-=--