Subject: Re: CVS commit: pkgsrc/mk/flavor/pkg
To: Dieter Baron <>
From: Greg Troxel <>
List: tech-pkg
Date: 07/18/2006 07:59:56
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):


So I suppose this could be


    Greg Troxel <>

Content-Type: application/pgp-signature

Version: GnuPG v1.4.4 (NetBSD)