Date: Mon, 5 Jan 1998 03:40:44 -0800 (PST) From: asami@cs.berkeley.edu (Satoshi Asami) To: jkh@time.cdrom.com Cc: current@FreeBSD.ORG Subject: Re: Time to retire fetch? Message-ID: <199801051140.DAA10749@baloon.mimi.com> In-Reply-To: <4721.883994636@time.cdrom.com> (jkh@time.cdrom.com)
next in thread | previous in thread | raw e-mail | index | archive | help
* 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801051140.DAA10749>