| 1 |
Paul de Vrieze wrote: |
| 2 |
> On Sunday 24 October 2004 05:18, Ed Grimm wrote: |
| 3 |
> |
| 4 |
>>Excluding program directories (for example, /etc/init.d), all changes to |
| 5 |
>>existing /etc files should compensate for changes that the local |
| 6 |
>>administrator has made. For example, when upgrading a configuration |
| 7 |
>>file, the new version should, as much as possible, retain the changes |
| 8 |
>>that the local administrator has made. When the ext3 filesystem tools |
| 9 |
>>add a new option, any attempts to update /etc/fstab should ignore any |
| 10 |
>>partitions that aren't ext3. It should not add any partitions that it |
| 11 |
>>feels are missing, either due to having ignored a reiserfs partition or |
| 12 |
>>due to that partition not being there. It should not alter any swap |
| 13 |
>>partitions that haven't been modified according to a change the ext3 |
| 14 |
>>maintainer previously saw - it's possible it may have not been installed |
| 15 |
>>here, it's possible the administrator backed it out. It should NEVER |
| 16 |
>>try to change the partition type (for example, from ext3 to xfs, like it |
| 17 |
>>currently wants to do.) |
| 18 |
> |
| 19 |
> |
| 20 |
> This is what dispatch-conf will do if you give it time to work. For |
| 21 |
> dispatch-conf to work you need to initialise it first. It works with |
| 22 |
> three-way diffs, so without a reference (which gets created the first time a |
| 23 |
> config file is updated with dispatch-conf) it doesn't work. For the rest, I |
| 24 |
> suggest you write up a patch to dispatch-conf to allow it to ignore certain |
| 25 |
> files. However it normally works quite well with fstab as the default one |
| 26 |
> hardly changes, and you'd want to know about those changes anyway. |
| 27 |
|
| 28 |
Thx to you and other kind replying people > |
| 29 |
|
| 30 |
I don't made yet my homeworks (studying dispatch-conf), so I was |
| 31 |
replying to Ed (with congrats), saying that was needed a 3 time diff. |
| 32 |
I think that could be more convenient the dispatch-conf way, but |
| 33 |
conceptually the creation of a reference is not mandatory. It's enough a |
| 34 |
diff between the actually installed and modified file and the original |
| 35 |
one of that version, since the system know which is the version of the |
| 36 |
original one. Then it knows which are the original lines that |
| 37 |
disappeared or changed and at that point it could delete such lines (or |
| 38 |
those that substitute them) from the new standard cfg file and merge |
| 39 |
only the remaining diffs and in any case it shouldn't never substitute |
| 40 |
custom changes with standard in cfg files. Then it could not be bad one |
| 41 |
comment line at the beginning of new std cfg file where is written what |
| 42 |
changed and why (I know that for the developers could be annoying, but |
| 43 |
it should not take more than 1-2 minutes). |
| 44 |
|
| 45 |
>>If people are interested, I could potentially write a tutorial on |
| 46 |
>>methods one could utilize to perform such functions. Note that this |
| 47 |
>>would be written to writing the code in perl, as I don't know python |
| 48 |
>>well, and it doesn't feel natural to me. |
| 49 |
> |
| 50 |
> |
| 51 |
> Well, go ahead |
| 52 |
> |
| 53 |
|
| 54 |
There are no problem, I know neither python neither perl, so I'm the |
| 55 |
perfect candidate to translate your perl script in python ;-) because |
| 56 |
I'd like to learn python. |
| 57 |
Anyway I know awk. |
| 58 |
|
| 59 |
Andrea |
| 60 |
|
| 61 |
P.S.: I'd like that someone for curiosity studied Conary to see what and |
| 62 |
how can be ported to gentoo portage, but I seen that my attempt has not |
| 63 |
been a very big success ;-), so maybe in my spare time, I'll try to do |
| 64 |
such thing myself and report here the results in the hope that you can |
| 65 |
teach me some about portage. |
| 66 |
|
| 67 |
-- |
| 68 |
gentoo-portage-dev@g.o mailing list |
Archives