From: Ryan Anderson <ryan@michonline.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: /etc in git?
Date: Fri, 20 Jan 2006 08:50:26 -0500 [thread overview]
Message-ID: <43D0EAA2.8090308@michonline.com> (raw)
In-Reply-To: <7vvewgirlt.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]
Junio C Hamano wrote:
>Ryan Anderson <ryan@michonline.com> writes:
>
>
>>Junio C Hamano wrote:
>>
>>
>>>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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]
next prev parent reply other threads:[~2006-01-20 13:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-19 3:43 /etc in git? Adam Hunt
2006-01-19 4:35 ` Junio C Hamano
2006-01-19 4:40 ` Adam Hunt
2006-01-19 4:59 ` H. Peter Anvin
2006-01-19 5:05 ` Junio C Hamano
2006-01-19 6:23 ` Ryan Anderson
2006-01-19 7:50 ` Junio C Hamano
2006-01-19 9:41 ` [PATCH] Support precise tracking of file modes Petr Baudis
2006-01-19 18:25 ` Junio C Hamano
2006-01-19 18:46 ` Petr Baudis
2006-01-20 15:27 ` Alex Riesen
2006-01-20 14:16 ` Peter Baumann
2006-01-20 13:50 ` Ryan Anderson [this message]
2006-01-20 17:55 ` /etc in git? Junio C Hamano
2006-01-19 16:54 ` Joel Becker
2006-01-19 22:22 ` Daniel Barkalow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43D0EAA2.8090308@michonline.com \
--to=ryan@michonline.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.