Subject: Re: FETCH_DEPENDS replacement?
To: Todd Vierling <tv@wasabisystems.com>
From: Jim Wise <jwise@draga.com>
List: tech-pkg
Date: 09/08/2000 19:52:33
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 8 Sep 2000, Todd Vierling wrote:

>On Fri, 8 Sep 2000, Jim Wise wrote:
>
>: I have this working fine.  However, as an HTTP POST is necessary to make
>: this work, the `urlget' package is needed to download swing.
>: 
>: IIRC, once upon a time, this could have been specified by putting
>: 
>: 	FETCH_DEPENDS+=	urlget:../../www/urlget
>: 
>: in the package Makefile.  This is no longer possible.
>
>This is beacuse fetch-based auto-building of packages was Very Bad, and that
>anything that was "that special" needed manual fetching.  Remember that
>"make fetch" is done recursively to fetch all the distfiles for
>ftp.netbsd.org:/pub/NetBSD/packages/distfiles, for one.

Hmm.  ISTM that it would have been easy enough to make FETCH_DEPENDS
processing able to be {dis,en}abled with a knob somewhere, but that's
fine.  I certainly see the concern.

>You *could* add a pre-fetch kludge, you will need to do so in some kind of
>conditional block that excludes recursive fetching.  I'm personally a bit
>frightened about that, though.  :>

Well, my gut feeling is that if someone types `make install' in a
package depending on swing, they _do_ want whatever steps taken as are
necessary to get and to install swing and any other dependencies of the
package they asked for.  I can see making it tunable for bulk fetches,
but that's not an issue for swing or jsdk20, both of which are
NO_SRC_ON_CDROM and NO_SRC_ON_FTP.

What do people think?  Is it acceptable to kludge in a dependency on
urlget in a pre-fetch target for swing and jsdk20 (both of which have
other packages which depend on them, remember), or should we stick with
the status quo, i.e. continue to require these to be downloaded by
hand...

- -- 
				Jim Wise
				jwise@draga.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (NetBSD)
Comment: For info see http://www.gnupg.org

iD8DBQE5uXvI2JhG4/qi8rQRAgBYAKCauG4PuFUg5T9is+u2lXjVx1kQsACghIMy
9funMAr9Bbhs87R2a1UEEHU=
=3mZN
-----END PGP SIGNATURE-----