Junio C Hamano wrote:
Ryan Anderson [off-list ref] writes:
quoted
Junio C Hamano wrote:
quoted
You are much better off to keep /usr/src/rootstuff/.git (and
working tree files are /usr/src/rootstuff/etc/hosts and
friends), have a build procedure (read: Makefile) there, and
version control that source directory. I usually have 'install'
and 'diff' target in that Makefile, so that I can do this:
...
If you're doing this, especially if you're doing this on multiple
machines, creating a package is probably a worthwhile thing to
contemplate as well.
In my workplace environment, the equivalent of the above
/usr/src/rootstuff is accessible throughout the networked
machines (mostly NFS mounted); for things that needs per-host
customization, we do not have /usr/src/rootstuff/etc/hosts but
keep /usr/src/rootstuff/etc/hosts.in as the source, and Makefile
customizes that into a form suitable for installation for each
machine. Especially useful is vfstab.in --- a single source
builds fstab for local mounting and nfs exports, while other
machines have mountpoints and project symlinks pointing into
location automounted from that machine with disk, generated
automatically. This does not match typical "package" use.
To provide an off-topic, but perhaps useful, counter-example, where I
work, I've made a package that does something similar.
I use a Makefile to generate a few template files, such as
/etc/resolv.conf, /etc/apt/preferences, /etc/sudoers, /etc/ntp.conf
It Pre-Depends on, ntp, sudo, (etc).
A postinstallation script does a little bit of tweaking of these files
based upon the answers to one or two questions asked during installation.
It's simply another way of looking at the problem.
--
Ryan Anderson
sometimes Pug Majere