From owner-freebsd-current@FreeBSD.ORG Mon Dec 5 02:21:37 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D9361065676; Mon, 5 Dec 2011 02:21:37 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 26D788FC0A; Mon, 5 Dec 2011 02:21:36 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id C9B64B852; Sun, 4 Dec 2011 18:04:44 -0800 (PST) To: Julian Elischer In-reply-to: Your message of "Sun, 04 Dec 2011 16:42:04 PST." <4EDC135C.5000400@freebsd.org> References: <20111202115446.GB25963@server.vk2pj.dyndns.org> <4ED974A2.7080606@FreeBSD.org> <4ED9EA27.8090206@inse.ru> <4EDABDE8.9060406@FreeBSD.org> <4EDBD5EF.9070207@freebsd.org> <4EDBE4A3.6010602@FreeBSD.org> <4EDC135C.5000400@freebsd.org> Comments: In-reply-to Julian Elischer message dated "Sun, 04 Dec 2011 16:42:04 -0800." Date: Sun, 04 Dec 2011 18:04:44 -0800 From: Bakul Shah Message-Id: <20111205020444.C9B64B852@mail.bitblocks.com> Cc: Randy Bush , freebsd-current Subject: Re: CVS removal from the base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 02:21:37 -0000 On Sun, 04 Dec 2011 16:42:04 PST Julian Elischer wrote: > On 12/4/11 3:36 PM, Randy Bush wrote: > > > > i suspect that my install pattern is similar to others > > o custom install so i can split filesystems the way i prefer, > > enabling net& ssh > > o pkg_add -r { bash, rsync, emacs-nox11 } (it's not a computer > > if it does not have emacs) > > o hack /etc/ssh/sshd_conf to allow root with password > > o rsync over ~root > > o hack /etc/ssh/sshd_conf to allow root only without-password > > o rsync over my standard /etc/foo (incl make.conf and src.conf) > > and other gunk > > o csup releng_X kernel, world, doc, ports > > o build and install kernel and world > > > > and then do whatever is special for this particular system. > > > > anything which would lessen/simplify the above would be much > > appreciated. anything not totally obiously wonderful which would > > increase/complicate the above would not be appreciated. > > my suggestion is that the 'sysports' or 'foundation ports' or > 'basic ports', (or whatever you want to call them) in their package > form come with the standard install in fact I'd suggest that they > get installed into some directory by default so that 'enabling' them > ata later time doesn't even have to fetch them to do the pkg_add. > > They have pre-installed entries in /etc/defaults/rc.conf. and only > their rc,d > files need to beinstalled into /etc along with their program files. > They are as close to being as they are now with the exception of > being installed in the final step instead of at the same time as the > rest of the stuff, > and it allows them to easily be 'deinstalled' and replaced by newer > versions. > > Some of them would come from the current system sources and some of > them would be > what are currently 'normal' ports but we consider them to be 'basic' > and 'extra supported' > > Examples of the first type would be bind, sendmail, cvs, and examples > of the second type would be perl, bash, maybe python, and possibly a > very minimal set of the > X11 packages. > > These are things we talk about having extra support for in the > installer anyhow. > I also suggest that said packages include a "plugin" for > sysinstall/bsdinstall. so that it can ask its own > quesitons during install. A while back I had toyed with a config based approach. The idea is you install a minimal system and then use one of the predefined system configs to bring the system upto a desired state. The same config will use your local script of the same name if one exists, to allow for local modifications. The same config (or an updated version) can be rerun after an update. Basically the idea is that you are dealing with a system as a _whole_ for the purpose of install/update/convert/replicate. You are capturing the "personality" or "metadata" of a system a single file (it in turn relies on a small set of small text files). This can be used for other purposes as well. A config is essentially names of packages to install, variable names, names of any pre/post external scripts to run, and other included configs. But no executable logic here! If this is used, a new release would also contain a repo for every predefined script -- this makes it easy to see what changed and deal with it. Benefits: - people can consistently customize their setup and keep it so after an upgrade - what is included in the "base system" becomes largely irrelevant - you can check/fix system personality at any time - you can generate a local config easily - can exactly replicate the same config on multiple machines - can systematically change the personality of your system - you can integrate this in sysinstall (and provide more flexibility) - you can define your own specialized configs for whatever purpose. To give you an idea: syscfg install # install foo on a new installation syscfg set # change existing (unconfigured) system to foo syscfg convert # change existing (configured) system to bar syscfg diff # compare local system against foo syscfg [-f] check # check and optionally fix syscfg update You would need to tell it where to get its data (either a released ISO or a site). Lot of details would have to be worked out. Unfortunately I don't get to use FreeBSD much these days @ work and my home setup doesn't change much.