From owner-cvs-ports  Mon Jul 17 18:36:08 1995
Return-Path: cvs-ports-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id SAA04204
          for cvs-ports-outgoing; Mon, 17 Jul 1995 18:36:08 -0700
Received: from silvia.HIP.Berkeley.EDU (silvia.HIP.Berkeley.EDU [136.152.64.181])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA04198
          ; Mon, 17 Jul 1995 18:36:03 -0700
Received: (from asami@localhost) by silvia.HIP.Berkeley.EDU (8.6.11/8.6.9) id SAA15584; Mon, 17 Jul 1995 18:36:00 -0700
Date: Mon, 17 Jul 1995 18:36:00 -0700
Message-Id: <199507180136.SAA15584@silvia.HIP.Berkeley.EDU>
To: ache@freebsd.org
CC: CVS-commiters@freefall.cdrom.com, cvs-ports@freefall.cdrom.com
In-reply-to: <IAqrc2mWZ2@deep-thought.demos.su> (ache@FreeBSD.org)
Subject: Re: cvs commit: ports/mail/pgpsendmail Makefile
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: cvs-ports-owner@freebsd.org
Precedence: bulk

 * >No, that's not what I said.  If we build a package of pgpsendmail, it
 * >will have the EXACT name of the pgp package (either American or
 * >non-American) in its dependency list, so we can't build a "generic"
 * >pgpsendmail package.
 * 
 * Well, it is already have EXACT name: /usr/ports/security/pgp
 * for both PGP versions. What prevent you to do generic package?

That's the *pathname* to the depended port, used from bsd.port.mk when
the user does a make by herself.  I'm talking about the PKGNAME built
into the package, that pkg_add uses when the user tries to install
pgpsendmail from a package.

 * I think, we need EXTRACT_DEPENDS, because package can be build several
 * times (for tuning/debugging purposes) and we really don't need to check
 * for extract program each build time.

Don't worry abut this, read the comments on BUILD_DEPENDS below.  This
reminds me of my original question, what was your INSTALL_DEPENDS for?

By the way, what I said in my previous mail:

 > Note that a dependency is built and installed only when you do
 > something of that stage or later; for instance, "make fetch" will only 
 > cause FETCH_DEPENDS stuff to be installed, the rest will just be
 > fetched; "make configure" will cause FETCH_DEPENDS and BUILD_DEPENDS
 > to be installed, etc.

was wrong.  The fetch stage of "make configure" will cause
FETCH_DEPENDS to be built and installed only if the fetch stage has to
be rerun, i.e., if the distfile is not available locally.

BUILD_DEPENDS will be built from within the extract target, so if you
do a "make build", try to fix a bug, remove work/.build_done and do a
"make build" again, the dependencies won't be checked again.

Satoshi