From owner-freebsd-binup Sun Oct 14 17: 5:19 2001 Delivered-To: freebsd-binup@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 885) id B376337B40C; Sun, 14 Oct 2001 17:05:15 -0700 (PDT) Date: Sun, 14 Oct 2001 17:05:15 -0700 From: Eric Melville To: binup@FreeBSD.org Subject: design issues Message-ID: <20011014170515.B39749@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-binup@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This weekend I sat down to work on some code for the binary updater, but I didn't really get anything done because I thought that a few important decisions where yet to be made, and really affect what I'm going to be working on next. 1. I've heard speculation of an entirely new package framework, that would include things such as base system components being installed as packages. Is this anywhere near reality for 5.0-RELEASE, or should it be considered a thought that has past? 2. Does it make sense for system components to include other components, or would managing dependancies within the updater sound like a better plan? In the case of the base system being installed as a set of packages it sounds like a better plan to manage dependancies, whereas with the current layout of FreeBSD it may make more sense to go the other way. 3. A means of classifying packages would be desirable to allow, say, the installation of a system using postfix instead of sendmail. This would work along the lines of certain packages being grouped, and then exactly one must be selected. This isn't really a question so much as an extra point to be considered in the first question. 4. There should be a reasonable way of accomplishing such tasks as adding groups without user intervention, and most certainly without destroying any of the existing configuration. One solution would involve dividing files across a generic and local version, such as currently done with rc.conf. Another would involve sending the client scripts that would be executed on their end, updating files as needed. How do these sound? What other solutions are there? All input is welcome. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-binup" in the body of the message