From owner-cvs-etc  Wed Oct  8 05:07:53 1997
Return-Path: <owner-cvs-etc>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id FAA13483
          for cvs-etc-outgoing; Wed, 8 Oct 1997 05:07:53 -0700 (PDT)
          (envelope-from owner-cvs-etc)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA13477;
          Wed, 8 Oct 1997 05:07:46 -0700 (PDT)
          (envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id FAA25273; Wed, 8 Oct 1997 05:07:09 -0700 (PDT)
To: asami@cs.berkeley.edu (Satoshi Asami)
cc: jkh@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG,
        cvs-etc@FreeBSD.ORG
Subject: Re: cvs commit: src/etc make.conf 
In-reply-to: Your message of "Wed, 08 Oct 1997 04:52:33 PDT."
             <199710081152.EAA13155@silvia.HIP.Berkeley.EDU> 
Date: Wed, 08 Oct 1997 05:07:09 -0700
Message-ID: <25269.876312429@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-cvs-etc@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Could be.

I'll check it out and get back to y'all. ;)

> This is a known problem.  Look at the Makefile.  Maybe we should come
> up with a better way to obtain a "skeleton" info/dir file.

Well, I'd think that at the very least, it should say "hey, I'm not
going to install the info file because you didn't install the info
distribution, you big doody-head."  It shouldn't just throw up its
hands and abort the whole install. ;-)

>  * Hmm.  OK, I guess I should put it back the way it was then, but we
>  * still need to make fetch deal with empty // specs then.
> 
> If it's incorrect to have a double-slash, we should fix all the ports
> and relevant files (just add a trailing slash to all the DIST_SUBDIR
> and MASTER_SITE_SUBDIRs).  But that has to wait until after 2.2.5, as
> the current set of files at least work for 2.2-stable and I don't want 
> to go change too many things now.

Well, we can certainly make fetch(1) deal with it as a work-around if
nothing else.  I don't think that this is a long-term problem, and
the change has been reverted.

					Jordan