Re: CVS removal from the base

On Sun, 04 Dec 2011 16:42:04 PST Julian Elischer <julian_at_freebsd.org>  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 <foo>	# install foo on a new installation
syscfg set <foo>	# change existing (unconfigured) system to foo
syscfg convert <bar>	# change existing (configured) system to bar
syscfg diff <foo>	# 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 _at_
work and my home setup doesn't change much.