Subject: Re: removing RUN_DEPENDS
To: None <>
From: Frederick Bruckman <>
List: tech-pkg
Date: 02/28/2000 00:12:50
On Mon, 28 Feb 2000, Hubert Feyrer wrote:

> On Sun, 27 Feb 2000, Frederick Bruckman wrote:
> > Yeah, it's not especially useful like it is. I have some idea to use
> > RUN_DEPENDS differently, but I don't have time to develop it right now.
> I assume you'll let tech-pkg know when the time is ripe. 
> What do we do with the unused code until then? (Affected are at least the
> references to RUN_DEPENDS and run-depends, and - see my other mail -
> build-depends, BUILD_DEPENDS and esp. the DEPENDS_USE macro).

Now that I think about it, there really isn't anything useful there. I
would want RUN_DEPENDS to hinge on a package, and not a binary. I
hadn't really thought about it for the BUILD_DEPENDS, but it makes
sense now that we can use wildcards and dewey depends.

> > OK, not the update target as such, but the deinstall target (1.408).
> > It's not clear to me why it's necessary, only now, to delete the
> > BUILD_DEPENDS. Even if you have a package that requires a particular
> > version of, say, automake to build, you still lose when the user runs
> > "pkg_delete" manually.
> OK, IC... i'm not familiar with the update code - can you see if the
> following makes things better (in the root-deinstall target):
> -.if (${DEINSTALLDEPENDS} != "NO")

Hmmm. This would make "ALL", which is set unconditionally by the
update target, lie somewhere between NO and YES:

DEINSTALLDEPENDS=YES	"pkg_delete -r -R" + pkg_delete BUILD_DEPENDS
> (Although that's probably broken from the naming but hey, I was not the
> one who overloaded the simple yes/no interface :-)

Yeah, the "ALL" thing is wierd.