From owner-cvs-all@FreeBSD.ORG Tue Jan 27 02:26:53 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 683) id C9A8016A4CF; Tue, 27 Jan 2004 02:26:53 -0800 (PST) Date: Tue, 27 Jan 2004 02:26:53 -0800 From: Eivind Eklund To: Wes Peters Message-ID: <20040127102653.GA92796@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401262048.58375.wes@softweyr.com> User-Agent: Mutt/1.4.1i cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: Ruslan Ermilov cc: cvs-all@FreeBSD.org cc: Dag-Erling Smorgrav Subject: Re: cvs commit: src/usr.bin/fetch fetch.1 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jan 2004 10:26:54 -0000 On Mon, Jan 26, 2004 at 08:48:58PM -0800, Wes Peters wrote: > On Monday 26 January 2004 07:05 am, Eivind Eklund wrote: > > My feeling about this is that we are giving our users a lot of > > inconvenience in the search for some kind of "idelogical purity" (in > > the form of consistency), where the purity does not buy us much. > > Purity should not be a goal in and of itself. Purity is a tool for > > making the system as a whole easier to deal with - a powerful, > > important and good tool, but a tool. > > > > I've had repeated cases of support on these variables because users do > > not find them. I agree with DES about duplication - I just think that > > the variables should be documented in fetch.1 instead of fetch.3. > > I agree with you in general, Eivind. Have you had a change to read the > change I committed? No - just after I had sent that e-mail somebody informed me of a deadline this morning, and I didn't have time to do much more about the issue :-( > It reads: > > All environment variables mentioned in the documentation for the fetch(3) > library are supported. A number of these are quite important to the > proper operation of fetch; you are strongly encouraged to read fetch(3) > as well. > > I hope this is strong enough "encouragement" for them to read the > definitive source. This looks good. When Ruslan sent the comment about pkg_add, I immediately thought of adding something similar, and did a 5-liner for pkg_add (as part of a patch I was going to include): Index: pkg_add.1 =================================================================== RCS file: /home/ncvs/src/usr.sbin/pkg_install/add/pkg_add.1,v retrieving revision 1.60 diff -u -r1.60 pkg_add.1 --- pkg_add.1 22 May 2003 11:56:41 -0000 1.60 +++ pkg_add.1 27 Jan 2004 09:51:46 -0000 @@ -444,6 +444,13 @@ .Fl r option is invoked. Thus it should be a complete URL to the remote package file(s). +.Ev +There is a lot of environment variables that can be set to influence the +behaviour of +.Xr fetch 3 , +which +.Nm +use to retrieve packages from the network. .Sh FILES .Bl -tag -width /var/db/pkg -compact .It Pa /var/tmp Feel free to use whatever part you might find useful (if any). Eivind.