Manoj Srivastava <sriva...@debian.org> wrote: > On Sat, Feb 21 2009, Jörg Sommer wrote: >> 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 > > I don't see how you can get that. There is no "file shipped with > the package" when you use ucf.
Right, but when I hook into apt-get, I can get the configuration file shipped with the packages. But that has nothing to do with ucf. >> the configuration files modified by the administrator are stored. The >> former branch is updated when ucf or apt-get is run. Then these > > How is the former branch updated with the new version, since you > are using UCF_FORCE_CONFFOLD? The documented effect is to retain > whatever was on the file system, no matter what. Therefore, I use the wrapper around ucf. The postinst script calls ucf <New File> <Destination> So I've the new file and know where it should go. I can update the file in the branch with the original files and then merge this branch with the local configuration branch and install this result underneath /etc. Then the real ucf can update it's database, but it should not touch the file I've put underneath /etc. It's save_original merge_with_current export UCF_FORCE_CONFFOLD=1 ucf.etcgit "$@" >> 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. > > In other words, totally remove whatever functionality ucf > offers Not remove, but etcgit reimplements it. > Anything else should be reflected in a conflicts relationship > between ucf and etckeeper, not a diversion, since the diversion does > not actually maintain the functionality of ucf. Interesting idea. Etcgit could replace ucf. I'll think about it. Bye, Jörg. -- Man soll Denken lehren, nicht Gedachtes. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
