Date: Mon, 08 Sep 1997 00:37:27 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Greg Lehey <grog@lemis.com> Cc: FreeBSD Hackers <hackers@FreeBSD.ORG> Subject: Re: Do you have some neat configuration files? Message-ID: <23971.873704247@time.cdrom.com> In-Reply-To: Your message of "Mon, 08 Sep 1997 15:38:22 %2B0930." <19970908153822.27586@lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> course, derived from what I run on my own system. In order to make > things easier for the user, I'm putting them on the CD-ROM, so anybody > who wants to use this version can just load the stuff from CD-ROM and > have a relatively functional system. > ... > I haven't decided on a structure for storing these files yet, though > Jordan has suggested a top-level directory /usr/share/skel/extras. > I'd suggest one subdirectory for each unrelated set of config files. Some folks will probably read the above and go "Squaaawk! Those are entirely unrelated items!" so let me just note that Greg's second paragraph there actually pertains to another aspect of this topic entirely which, while entertwined in a common subject thread, is nonetheless distinct from the CD issues. Greg has really placed two separate proposals here before you, the first being the collection of some nifty startup file bits and "canned user profiles" which Joe User might crib from, just as hackers on true timesharing UNIX systems used to crib useful tidbits from various admin personnel's startup files when left readable, and the second being the actual incorporation of this data into the CVS repository for more ongoing "skeleton file" work. His book could certainly reference these files under xperimnt/ on the CD just as easily and avoid the whole question of how to organize the contents more generally, but I also think that putting this stuff into /usr/share/skel/extras might very well lead to something far nicer in the long run due to the extra exposure and collaborative opportunities bestowed by the CVS repository. It's a tough call. In any case, I think we should be careful to keep the issues separate so that if one battle is lost the whole "war" doesn't go with it. An attempt to gather this information was made once before and it failed. I'd hate to see that happen twice. :-) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23971.873704247>