From owner-freebsd-hackers Fri Dec 18 10:27:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA09938 for freebsd-hackers-outgoing; Fri, 18 Dec 1998 10:27:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA09932 for ; Fri, 18 Dec 1998 10:27:03 -0800 (PST) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA22073; Fri, 18 Dec 1998 11:26:48 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp02.primenet.com, id smtpd021882; Fri Dec 18 11:26:41 1998 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id LAA21025; Fri, 18 Dec 1998 11:26:11 -0700 (MST) From: Terry Lambert Message-Id: <199812181826.LAA21025@usr01.primenet.com> Subject: Re: Back to sysinstall To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Date: Fri, 18 Dec 1998 18:26:11 +0000 (GMT) Cc: dkelly@hiwaay.net, FreeBSD-Hackers@FreeBSD.ORG In-Reply-To: <86839.913956347@zippy.cdrom.com> from "Jordan K. Hubbard" at Dec 17, 98 08:45:47 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What happens when you want to *add* to the set of installed things > via make world? You make them, then you install them, in two steps. > Or when you've made local changes to your src tree, made the > world, and now a binary update comes in for something that > you've updated? Local versioning. Ideally, FreeBSD source would come into your local tree on a vendor branch. That would allow people without commit priviledges to be able to apply source code control to their local modifications, in the contexts in which it is used. > Clearly, you don't want your local mods to be spammed and this > is what requires a fair bit of work. Define two axes of major version number, and only allow automatic update along one axis. FreeBSD controls one axis, and local user changes go on the other. > Believe me, this whole thing is infinitely easy to conceptualize and > has been for at least 3 years. That's not where the real work or > discussion is. What takes the real work, and is where you need to > focus your efforts if you're serious about jumping in on this one with > us, is figuring out how to actually IMPLEMENT such a scheme that takes > into account all the possible variants. Mike and I have both spent a > fair amount of time doing this and can only say that it's a lot harder > than it looks once you start really enumerating the possible upgrade > scenarios. Actually, it's pretty easy. Do Exactly What SCO Does With Their Packages(tm). SCO has been able to upgrade system components on a file by file basis since the mid 1980's Xenix heydays. It's no sin to plagarize documented architecture from someone else, especially when it resolves your problems at the same time. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message