1 |
Hi Jonas, |
2 |
|
3 |
First, I think this is an interesting approach, especially because it |
4 |
tries to be more than just /etc in $VCS, IMO. |
5 |
|
6 |
Some general remarks, /etc should be what's in CONFIG_PROTECT, which can |
7 |
be multiple locations IIRC. Next, I'd prefer the proposal to be mildly |
8 |
VCS agnostic. I for one can much easier mess around with CVS and SVN, |
9 |
then with bzr, git, hg, etc. Just a bit of taste. |
10 |
|
11 |
I'm going to cut some huge parts from your mail, and respond ;) |
12 |
|
13 |
On 26-03-2009 03:11:54 +0100, Jonas Bernoulli wrote: |
14 |
> For various reasons "etc-under-version-control" loses much of the |
15 |
> power and/or ease of use that comes with the underlying vcs. Much of |
16 |
> this being due to the fact that the files being kept in the repository |
17 |
> are totally unrelated. |
18 |
|
19 |
I think Jeremy already hinted at this, you probably should try to |
20 |
make your point somewhat stronger here. Maybe "conceptual cleanness", |
21 |
and the benefits you get with that e.g. when removing a package (and |
22 |
it's config files!) will give you a convincing story. |
23 |
|
24 |
> The solution to this obviously is to maintain a separate branch for |
25 |
> each package. And just as obvious one big problem is that the config |
26 |
> files of most applications are mangled into the same location namely |
27 |
> /etc (and elsewhere) making hard to impossible to use normal vc |
28 |
> commands related to branches. |
29 |
|
30 |
A branch, or maybe just separate modules? Like you said, it's totally |
31 |
unrelated, so why would it be in the same module? |
32 |
|
33 |
> To those not familiar with git what this basically does is to checkout |
34 |
> the branch containing the live files of $package without removing any |
35 |
> files that are not part of the branch - it's faking a checkout without |
36 |
> actually performing one. It's a bit more complex than that but this |
37 |
> is what basically has to be done since we can not remove files not |
38 |
> belonging to a package from /etc. We are on a live system after all |
39 |
> and these files might be required while we configure $package. |
40 |
|
41 |
Just toying with some thoughts here. Suppose that /etc is a "read-only" |
42 |
export of your vcs contents somehow. One could say that all known (and |
43 |
active?) modules are exported into some some clean image, and then that |
44 |
image is made active in /etc (removing stuff that is not in the image, |
45 |
e.g. rsync -a --delete). |
46 |
How this image is generated can be using your GIT thing, or some other |
47 |
approach that would work fine with multiple CVS/SVN modules. |
48 |
The important part, is that you can somehow enter a virtual |
49 |
chroot/sandbox with just the configuration files of package X, where you |
50 |
have VCS stuff, such that you can do whatever you need to do. |
51 |
|
52 |
> So one could simply write a shell script that extends the above mockup |
53 |
> to be run before and after work on the config files of $package. |
54 |
> While this would be an improvement over etc-under-vc it is still very |
55 |
> impractial to use. |
56 |
|
57 |
Portage would indeed "mount" the same sandbox, and commit any changes. |
58 |
One can think about branches or tags, which IMO is VCS and user |
59 |
specific. Some people might like to have separate branches (one with |
60 |
vanilla stuff committed by Portage, the other with their own changes). |
61 |
|
62 |
> After the files are copied to the live system and if there are no |
63 |
> conflicts git can not resolve (there will be less conflicts than |
64 |
> currently) the 'vanilla' branch is merged into the 'live' branch. |
65 |
|
66 |
Is this an automatic merge of a branch into another branch, or is this |
67 |
an update of a modified working copy? Just to be sure, I think if you |
68 |
have a VCS at hand anyway, you want to commit your config files to it ;) |
69 |
|
70 |
> If on the other hand automatic merging is not possible for all files |
71 |
> then only the conflict-free files are copied to the live system and |
72 |
> the package is added to a list of packages that have to be later |
73 |
> merged. |
74 |
|
75 |
Question, should this happen automatically at all? If you made no |
76 |
changes to a config file, no conflicts will happen. If you did made |
77 |
some changes, maybe you better wait for the user to review them. |
78 |
Probably a three-way option here to match the user's preferences. |
79 |
|
80 |
Example why automatic merging (without conflicts) that is not desirable: |
81 |
|
82 |
# |
83 |
+# wipe / on every boot |
84 |
+rm -Rf / |
85 |
# |
86 |
|
87 |
ok, made up, but some people might not like cleaning /tmp on boot. |
88 |
|
89 |
> This tool won't be limited to the task of replacing etc-update. It is |
90 |
> also used to commit changes to configuration files made during daily |
91 |
> use. It should also support many of the operations that the |
92 |
> underlying git supports while providing something like the above |
93 |
> mockup split in the two obvious parts so that git can be used directly |
94 |
> in hairy cases. This tool should feature an expert (plumbing) mode as |
95 |
> well as a simple (porcelain) mode suitable for people not willing to |
96 |
> learn about git. Generally the interface will be similar to that of |
97 |
> git. |
98 |
|
99 |
I think this would be easier to achieve when you say the target (/etc) |
100 |
is read-only, and just regenerated upon every commit to any of the |
101 |
packages that you "edit" through confsync. |
102 |
|
103 |
> Not only does above description not contain all relevant details it |
104 |
> also does not list most benefits that confsink offers. For one, |
105 |
> confsink would allow easier sharing of configuration between multiple |
106 |
> machines and even users. |
107 |
|
108 |
That's an extension that probably should be stressed a bit more, as it |
109 |
would allow for clusters to solve the problem when updating package X |
110 |
(from binpkg) still results in config files not being changed |
111 |
appropriately. Tools like puppet can help in setting config files here, |
112 |
but what is nicer than a system where upgrading a package immediately |
113 |
gets the proper configuration from the master? |
114 |
|
115 |
|
116 |
-- |
117 |
Fabian Groffen |
118 |
Gentoo on a different level |