From owner-freebsd-current  Mon Jan  5 03:40:55 1998
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id DAA24360
          for current-outgoing; Mon, 5 Jan 1998 03:40:55 -0800 (PST)
          (envelope-from owner-freebsd-current)
Received: from baloon.mimi.com (sjx-ca124-61.ix.netcom.com [207.223.162.189])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA24354
          for <current@FreeBSD.ORG>; Mon, 5 Jan 1998 03:40:50 -0800 (PST)
          (envelope-from asami@vader.cs.berkeley.edu)
Received: (from asami@localhost)
	by baloon.mimi.com (8.8.8/8.8.8) id DAA10749;
	Mon, 5 Jan 1998 03:40:44 -0800 (PST)
	(envelope-from asami)
Date: Mon, 5 Jan 1998 03:40:44 -0800 (PST)
Message-Id: <199801051140.DAA10749@baloon.mimi.com>
To: jkh@time.cdrom.com
CC: current@FreeBSD.ORG
In-reply-to: <4721.883994636@time.cdrom.com> (jkh@time.cdrom.com)
Subject: Re: Time to retire fetch?
From: asami@cs.berkeley.edu (Satoshi Asami)
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

 * 	1. Do we want to retire fetch and just use ftp now as our
 * 	   FETCH_CMD in -current?  Would any fetch features be missed
 * 	   that would also be overtly difficult to merge into the ftp
 * 	   client?  Strengthening one tool rather than putting two
 * 	   into competition is obviously a worthy goal if it's possible
 * 	   to do it.

See 3.

 * 	2. Do we simply want to ignore this new feature of ftp, perhaps
 * 	   under the premise that having an ftp client fetch http URLs
 * 	   is rather counter-intuitive if one is a stickler for naming
 * 	   conventions, and just go on like we are now?

That's the problem of ftp merge, not our (ports') problem.  Whatever
works is fine for us.

 * 	3. Given that ftp probably doesn't deal well with the file:/
 * 	   URLs that can also be passed to fetch(1) from the ports
 * 	   collection, does fetch(1) perhaps want to stick around but
 * 	   simply become a smaller pre-parsing script which hands its
 * 	   work off to other tools rather than doing it itself?

file: support is mandatory.  By default, bsd.port.mk even puts the
cdrom distfiles dir in front of the master sites list.

I also use it on my package building machine to keep copies of
RESTRICTED distfiles without risking it going out to the public.  It's
useful for my laptop too (it points file: to the NFS-mounted server's
distfiles dir).

To me, 3 sounds like the best approach.  However, we need to make sure 
fetch an ftp are compatible in all senses (e.g., whether you include
the full path when you go to a on-the-fly tarballing site).  I
remember ache mumbling something about non-anonymous ftp too.

Satoshi