Hi Manoj, Hi debian-devel, Manoj Srivastava hat am Fri 20. Feb, 12:04 (-0600) geschrieben: > On Fri, Feb 20 2009, Jörg Sommer wrote: > > > I'm packaging etcgit [1], a system to manage configuration files in /etc > > with git, similar to etckeeper. Etcgit tracks the original version of all > > files and therefore, I have to wrap ucf to get the original version and > > stop ucf from doing anything. The script [2] is mainly this: > > Shouldn't etcgit be tracking the current state as well as the > original versions? Yes, it does so. In one branch it tracks the original configuration files as given to ucf and as shipped with the packages. In a second branch the configuration files modified by the administrator are stored. The former branch is updated when ucf or apt-get is run. Then these changes are merged into the branch with the local configurations. If a confict happens, the user has to solve it manually. > Also, I am not sure that this is valid. ucf is merely a toll > for the administrator to select what the local configuration file > contains; and as such is logically similar to vi or emacs. If you are > nto planning on wrapping vi-and-variants, and various emacsen, why wrap > ucf? No, it's up to the administrator to make commits to etcgit after changes to any file. Etcgit refuses to continue with apt-get if there are uncommited changes. > > save_original > > merge_with_current > > export UCF_FORCE_CONFFOLD=1 > > NAK. > > I think this is wrong. This essentially says that ucf should > never present the new config file to the user, even if keeping the old > configuration files breaks the system. Yes, ucf should not touch the configuration file, because the merge was done by etcgit. When ucf sees the “old” configuration file it's already updated by etcgit. The ucf call is only to let ucf update it's internal database. Regards, Jörg. -- Was man mühelos erreichen kann, ist gewöhnlich nicht der Mühe wert, erreicht zu werden.
Attachment:
signature.asc
Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP