From owner-freebsd-chat Mon Aug 25 16:36:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA20505 for chat-outgoing; Mon, 25 Aug 1997 16:36:04 -0700 (PDT) Received: from hwcn.org (main.hwcn.org [199.212.94.65]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA20485 for ; Mon, 25 Aug 1997 16:36:00 -0700 (PDT) Received: from james.freenet.hamilton.on.ca (ac199@james.hwcn.org [199.212.94.66]) by hwcn.org (8.8.7/8.8.7) with ESMTP id TAA09642; Mon, 25 Aug 1997 19:36:07 -0400 (EDT) Received: from localhost (ac199@localhost) by james.freenet.hamilton.on.ca (8.8.7/8.8.7) with SMTP id TAA23625; Mon, 25 Aug 1997 19:36:22 -0400 (EDT) X-Authentication-Warning: james.freenet.hamilton.on.ca: ac199 owned process doing -bs Date: Mon, 25 Aug 1997 19:36:21 -0400 (EDT) From: Tim Vanderhoek X-Sender: ac199@james.freenet.hamilton.on.ca Reply-To: hoek@hwcn.org To: rdkeys@csemail.cropsci.ncsu.edu cc: freebsd-chat@FreeBSD.ORG Subject: Re: Suggestions from a unix dummy..... In-Reply-To: <9708251652.AA129381@csemail.cropsci.ncsu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 25 Aug 1997 rdkeys@csemail.cropsci.ncsu.edu wrote: > Applying unix dummies dunce cap and sitting on yon stool in the corner..... > > What about setting up the ftp install scripts and the archive trees > something like..... > > FreeBSD/x.x.x.x-release/ > FreeBSD/x.x.x.x-release/binary > FreeBSD/x.x.x.x-release/sources [repeated for -stable and -current] I'm not sure that this wins us very much. The source for every version of every file is available via CVS (there is a nice web-interface on www.freebsd.org). Separate binary-source dirs really don't buy much (actually, they probably cost more since more ftp connections would have to be negotiated). > FreeBSD/bootdisks/ Unfortunately, bootdisks _really_ are tied to releases. Even if they could be separated, that would mostly create confusions and problems (you need min. version x to install ver.x of FreeBSD, and don't forget to report your bootdisk version in any questions you ask). > Move the releng thing into current-stable. It is a good idea, but > its nomenclature is confusing. "releng", I believe, comes mostly from the nature of the CVS repository. 2.2 is developed, giving you 2.2-releng, 2.1 is developed, giving you 2.1-releng. -stable is the correct term. > Move the development work from 3.0 into current-development. It is > a good idea, but 3.0 is not yet 3.0, but it is ``current-development''. BINGO! You win a prize! Now, if everyone else can just be taught that. The unfortunate problem is that -current needs a version number of some sort. It's definately not 2.x, and, since it will eventually be 3.x, it identifies itself as such. However, it should _never_ be referred to as FreeBSD 3.0, only as FreeBSD-970901-SNAP or FreeBSD-current. > A VERSION file in appropriate directories would tell you the current > version number for any current tree, or release tree, and could be > parsed by the install scripts to confirm the validity of the tree, > if need be. $ uname -r > Forget about snaps, except as archive trees for the normal time > snaps are kept around in the archive subdirectories, just for reference. > The naming blows up the install scripts if your install disk is only > a little out of sync. It is a good idea, but the nomenclature in > naming is marginal. There's already -release, -current, -stable, so why not -snap? > Put all the ports in one place, and make any port buildable on any You mean in one big directory? Um. Hm. No. :-) > release or any current-stable or current-development box. Maybe > this would make many less headaches in out of sync ports. It should > be entirely possible in principle and probably in practice to make any > port build on any release from 2.1.7.1 up through the latest current Officially ports are only supported on -stable. This is to keep the amount of work manageable. However, if you find a port that doesn't work on -current or any other release (PROVIDED you are using an up-to-date bsd.port.mk and friends), you are encouraged to send patches in a pr. > That way, all the install scripts install from ONE AND ONLY ONE > pointer. You don't wind up with your snap vaporized a week down the I'm not sure I see how you solved that ("snap vapourized") problem. Keeping snaps hanging around forever is not really an option. I've found from empirical evidence that it's only a minor (if at all) problem. Besides, -snap is not -release; if you install -snap, you should be prepared to reinstall shortly down the road. > road. YOU ALWAYS GET THE CURRENT SNAP FROM ANY INSTALL DISK (verrrrrry > important and goooooood for us dummy folks --- saveum lotsa headscratchums). dummy folks shouldn't install -snap. :-) Don't forget: -snap is -current. -- Outnumbered? Maybe. Outspoken? Never! tIM...HOEk