Re: ucf: Diversion of /u/b/ucf by etcgit
Hi Manoj, Manoj Srivastava sriva...@debian.org wrote: On Sun, Feb 22 2009, Jörg Sommer wrote: Manoj Srivastava sriva...@debian.org wrote: On Sun, Feb 22 2009, Jörg Sommer wrote: Manoj Srivastava sriva...@debian.org wrote: On Sat, Feb 21 2009, Jörg Sommer wrote: 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. What does hook into apt-get mean? I use the hooks Pre-Install-Pkgs and Post-Invoke as provided by apt-get. What happens if I do a dpkg -i? Nothing. You have to update the branches by hand. And yet you are proposing to divert ucf? What do you suggest should happen when you run dpkg -i? What should etcgit do? etcgit should work whether or not it was aptitude, synaptic, apt-get, or dpkg which was used to install the package. The part I am worried about is whether the wrapper allows ucf to do its job; namely, ask the use what they want to do with any changes in configuration files. I've changed the wrapper of ucf to do nothing and pass full control over to ucf until enable_ucf_wrapper is set to yes in /etc/etcgit.conf. This isn't set by default, so after installation of the package the user has to enable the wrapper manually. Therefore, ucf works the same as without etcgit until the user sets the variable. Is this fine for you? Can I upload the package? What do you prever what I should do with the manual page? Should I divert the manual page, too, so the user gets the manual page of the ucf wrapper when he types “man ucf” or should I let the manual page stay and add a manual page for the diverted ucf? 1. man ucf gives original manual page and man ucf.etcgit give the manual page for the wrapper, while ucf is the wrapper and ucf.etcgit is the original ucf. This has the advantage that you get the commands and options of ucf with “man ucf.” 2. man ucf explains ucf was redirected and the user has to look at man ucf.etcgit to find the options of ucf. Bye, Jörg. -- Wer einen Traum verwirklichen will, muss erst aufwachen. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
On Wed, Apr 22 2009, Jörg Sommer wrote: I've changed the wrapper of ucf to do nothing and pass full control over to ucf until enable_ucf_wrapper is set to yes in /etc/etcgit.conf. This isn't set by default, so after installation of the package the user has to enable the wrapper manually. Therefore, ucf works the same as without etcgit until the user sets the variable. OK. This way, the user takes control, and bears the responsibility, which is ok. Is this fine for you? Can I upload the package? Sure. What do you prever what I should do with the manual page? Should I divert the manual page, too, so the user gets the manual page of the ucf wrapper when he types “man ucf” or should I let the manual page stay and add a manual page for the diverted ucf? I think if /usr/bin/ucf is diverted, so should the man page be. 1. man ucf gives original manual page and man ucf.etcgit give the manual page for the wrapper, while ucf is the wrapper and ucf.etcgit is the original ucf. This has the advantage that you get the commands and options of ucf with “man ucf.” 2. man ucf explains ucf was redirected and the user has to look at man ucf.etcgit to find the options of ucf. The second option is the right one, I think. The new man page should have some information of what changes the users can expect if the turn on enable_ucf_wrapper; but apart from that, this sounds good. manoj -- Anyone who has never made a mistake has never tried anything new. Albert Einstein Quotes On People and Life: Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
On Mon, Feb 23 2009, sean finney wrote: On Mon, Feb 23, 2009 at 09:24:17PM +0100, Frank Küster wrote: (1) I use the hooks provided by apt to get the original files from the package In other words, with ucf you get NOTHING, since there are no original files in the package. They are only created temporarily while postinst is run. i think what you really want[1] is something mentioned earlier back in the thread, where ucf provides a set of run-hooks that you could exploit for the purposes of tracking files, thus eliminating the need for diverting ucf at all. Patches welcome. People interested in contributing to this discussion, or to development of ucf in general, might be interested in this blog post: http://www.golden-gryphon.com/blog/manoj/blog/2009/02/24/Rethinking_ucf/ manoj ps: If someone could point me to a howto to enable comments posting for my blog using ikiwiki, I'd be grateful: I am using the comments plugin, but I think something is all whack with my setup -- What's love but a second-hand emotion? Tina Turner Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
Jörg Sommer jo...@alea.gnuu.de wrote: But I can get the files dpkg installs in /etc. That's enough for the first step. I don't want to create an AI that does everything right. One step after the other! No, dpkg installs _nothing_ in /etc for ucf related files Right, but your are mixing two different things. NO, you don't seem to understand what ucf is for, and is doing. (1) I use the hooks provided by apt to get the original files from the package In other words, with ucf you get NOTHING, since there are no original files in the package. They are only created temporarily while postinst is run. Regards, Frank -- Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
On Mon, Feb 23, 2009 at 09:24:17PM +0100, Frank Küster wrote: (1) I use the hooks provided by apt to get the original files from the package In other words, with ucf you get NOTHING, since there are no original files in the package. They are only created temporarily while postinst is run. i think what you really want[1] is something mentioned earlier back in the thread, where ucf provides a set of run-hooks that you could exploit for the purposes of tracking files, thus eliminating the need for diverting ucf at all. sean [1] i make no claims of being psychic or clairvoyant of course signature.asc Description: Digital signature
Re: ucf: Diversion of /u/b/ucf by etcgit
Manoj Srivastava wrote: I think the correct thing for the wrapper to do is a) change branch to the upstram_version_branch, and commit the new upstream. b) Change back to the local branch c) run ucf and let the user do their thing (replace, not replace, edit, whatever). d) Commit the result to the local_changed_branch. I also think this would be a good think. But perhaps, ucf can be improved to detect this situation (perhaps a new option that etcgit add before calling the real ucf) and can propose a new way to resolve the confict : - use old conffile - use new conffile - see diff - try experimental 3 way merge - ... - merge with etcgit - new option for the user If selected, the new option will run a callback provided by etcgit that will merge the corresponding branches with git. You will need to discuss between you to define properly the interfaces. It is also possible to improve ucf to propose new generic ways of handling merges (and perhaps storing the original file and the resulted file) just by installing callback scripts. Then etcgit or other similar packages will be able to install their hooks without messing with provides/conflicts/diversions/... of ucf Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
Jörg Sommer jo...@alea.gnuu.de wrote: Right, but when I hook into apt-get, I can get the configuration file shipped with the packages. You cannot, since the very purpose of ucf is to give dpkg-conffile-like behavior for configuration files *not* shipped in the package. Regards, Frank -- Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
On Sun, Feb 22 2009, Vincent Danjean wrote: Manoj Srivastava wrote: I think the correct thing for the wrapper to do is a) change branch to the upstram_version_branch, and commit the new upstream. b) Change back to the local branch c) run ucf and let the user do their thing (replace, not replace, edit, whatever). d) Commit the result to the local_changed_branch. I also think this would be a good think. But perhaps, ucf can be improved to detect this situation (perhaps a new option that etcgit add before calling the real ucf) and can propose a new way to resolve the confict : - use old conffile - use new conffile - see diff - try experimental 3 way merge - ... - merge with etcgit - new option for the user I'll be happy to review and accept a patch adding such a command-line option and a run-hook invovation to ucf. If selected, the new option will run a callback provided by etcgit that will merge the corresponding branches with git. Sounds good. You will need to discuss between you to define properly the interfaces. It is also possible to improve ucf to propose new generic ways of handling merges (and perhaps storing the original file and the resulted file) just by installing callback scripts. You know where to file wishlist bugs. Adding run-hook calls to parts of the ucf processing should be easy; specifying those hooks only slightly more complex. Then etcgit or other similar packages will be able to install their hooks without messing with provides/conflicts/diversions/... of ucf I am always open to feature requests (preferably with patches). However, I do not now, and do not plan in the future, to personally use etckeeper. I already have bit of my /etc in git, but I only keep files I have invested some effort into modifying in git, and I mainly care about the history of the file o disk, as opposed to upstream versions of the configuration file -- and I ma happy with this subset of etckeeper functionality. Given that, and my unfamiliarity with etckeeper internals, these enhancements to ucf won't happen without collaboration with people with knowledge of, and motivation for, things like etckeeper. manoj -- There is no snooze button on a cat who wants breakfast.-Unknown Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
Hi Steve, Steve Langasek vor...@debian.org wrote: On Sat, Feb 21, 2009 at 11:09:52PM +, Jörg Sommer wrote: save_original merge_with_current export UCF_FORCE_CONFFOLD=1 ucf.etcgit $@ So this will leave the ucf db with a horribly incorrect view Which bit in ucf's database would become invalid? Regards, Jörg. -- Du hast keine Chance – also nutze sie. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
Manoj Srivastava sriva...@debian.org wrote: On Sat, Feb 21 2009, Jörg Sommer wrote: 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. What does hook into apt-get mean? I use the hooks Pre-Install-Pkgs and Post-Invoke as provided by apt-get. What happens if I do a dpkg -i? Nothing. You have to update the branches by hand. Also, there might be nothing shipped with the package. You can't hook into apt-get to get the file generated in the postinst -- since there might not _be_ a upstream version at all until the postinst is run. You can with the Post-Invoke hook. I will consider adding a conflicts to the ucf package as well. Are you contented, when I disable the wrapper and add an option so the user can enable the wrapper if he likes or leave it if he dislikes? Regards, Jörg. -- Perfection is reached, not when there is no longer anything that can be added, but when there is no longer anything to take away. (Antoine de Saint‐Exupery) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
Hi Frank, Frank Küster fr...@debian.org wrote: Jörg Sommer jo...@alea.gnuu.de wrote: Right, but when I hook into apt-get, I can get the configuration file shipped with the packages. You cannot, since the very purpose of ucf is to give dpkg-conffile-like behavior for configuration files *not* shipped in the package. But I can get the files dpkg installs in /etc. That's enough for the first step. I don't want to create an AI that does everything right. One step after the other! Regards, Jörg. -- Nutze die Talente, die du hast. Die Wälder wären sehr still, wenn nur die begabtesten Vögel sängen.(Henry van Dyke) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
On Sun, Feb 22 2009, Jörg Sommer wrote: Hi Frank, Frank Küster fr...@debian.org wrote: Jörg Sommer jo...@alea.gnuu.de wrote: Right, but when I hook into apt-get, I can get the configuration file shipped with the packages. You cannot, since the very purpose of ucf is to give dpkg-conffile-like behavior for configuration files *not* shipped in the package. But I can get the files dpkg installs in /etc. That's enough for the first step. I don't want to create an AI that does everything right. One step after the other! No, dpkg installs _nothing_ in /etc for ucf related files -- so this is a failure as a first step, for ucf controlled configuration files. The configurations files are isntalled by ucf (and you propose disabling even that). So far from an artificial intelligence, you have accomplished what I would consider an RC bug (breaks unrelated packages justification). manoj -- For every problem there is one solution which is simple, neat, and wrong. Mencken Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
On Sun, Feb 22 2009, Jörg Sommer wrote: Manoj Srivastava sriva...@debian.org wrote: On Sat, Feb 21 2009, Jörg Sommer wrote: 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. What does hook into apt-get mean? I use the hooks Pre-Install-Pkgs and Post-Invoke as provided by apt-get. What happens if I do a dpkg -i? Nothing. You have to update the branches by hand. And yet you are proposing to divert ucf? I think this is a show-stopper. Also, there might be nothing shipped with the package. You can't hook into apt-get to get the file generated in the postinst -- since there might not _be_ a upstream version at all until the postinst is run. You can with the Post-Invoke hook. What will you get about the newly created file in the post-invoke hook? By the time the post-invoke hook is called, the file might be long gone -- and since ucf is being told to ignore the new file, you have lost it. I will consider adding a conflicts to the ucf package as well. Are you contented, when I disable the wrapper and add an option so the user can enable the wrapper if he likes or leave it if he dislikes? If you are going to divert ucf, I'll add a conflicts. If the end usr disables or diverts ucf locally, that is their problem, we give the users flexibility to shoot themselves in the foot. Please add a note that the wrapper is not supported by ucf,and if they isntall the wrapper, all bugs about it will be ignored/redirected to etckeeper. manoj -- Dead? No excuse for laying off work. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
Manoj Srivastava sriva...@debian.org wrote: On Sun, Feb 22 2009, Jörg Sommer wrote: Manoj Srivastava sriva...@debian.org wrote: On Sat, Feb 21 2009, Jörg Sommer wrote: 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. What does hook into apt-get mean? I use the hooks Pre-Install-Pkgs and Post-Invoke as provided by apt-get. What happens if I do a dpkg -i? Nothing. You have to update the branches by hand. And yet you are proposing to divert ucf? What do you suggest should happen when you run dpkg -i? What should etcgit do? Also, there might be nothing shipped with the package. You can't hook into apt-get to get the file generated in the postinst -- since there might not _be_ a upstream version at all until the postinst is run. You can with the Post-Invoke hook. What will you get about the newly created file in the post-invoke hook? The newly created file. I add it to the local branch to track the changes. I can't tell the user where it comes from nor in which way his file differs from the original, but it's in the tree. Nothing more. That's the same etckeeper does for many versions. And did you get any complains about your ucf acting wrong? By the time the post-invoke hook is called, the file might be long gone Why should it be gone? If someone (dpkg, ucf, a update-somthing tool or a maintainer script) puts a file underneath /etc, who should remove it? -- and since ucf is being told to ignore the new file, you have lost it. I only tell ucf to not touch the file if I can get it in the wrapper. If not the wrapper is invoked (or disabled), but the real ucf, I can't tell it to not touch the new file. I will consider adding a conflicts to the ucf package as well. Are you contented, when I disable the wrapper and add an option so the user can enable the wrapper if he likes or leave it if he dislikes? If you are going to divert ucf, I'll add a conflicts. But then you force me to replace ucf what I don't want to do. I offered the option to disable the wrapper by default and make everything works as if the wrapper isn't there. What's the problem? Bye, Jörg. -- Damit das Mögliche entsteht, muß immer wieder das Unmögliche versucht werden. (Hermann Hesse) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
Manoj Srivastava sriva...@debian.org wrote: On Sun, Feb 22 2009, Jörg Sommer wrote: Frank Küster fr...@debian.org wrote: Jörg Sommer jo...@alea.gnuu.de wrote: Right, but when I hook into apt-get, I can get the configuration file shipped with the packages. You cannot, since the very purpose of ucf is to give dpkg-conffile-like behavior for configuration files *not* shipped in the package. But I can get the files dpkg installs in /etc. That's enough for the first step. I don't want to create an AI that does everything right. One step after the other! No, dpkg installs _nothing_ in /etc for ucf related files Right, but your are mixing two different things. (1) I use the hooks provided by apt to get the original files from the package and the updated files after apt has done everything. This has nothing to do with the ucf wrapper! (2) And I use a wrapper for ucf to get the original file supplied by the maintainer script. The configurations files are isntalled by ucf (and you propose disabling even that). So far from an artificial intelligence, you have accomplished what I would consider an RC bug (breaks unrelated packages justification). But in this bug report you have to explain what broke. I please you, don't wait and tell it me now. Tell me what breaks when I divert ucf to ucf.etcgit and install this script as ucf: #!/bin/sh exec ucf.etcgit $@ Bye, Jörg. -- NetBSD ist für Frauen: es läuft auf Waschmaschinen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
On Sun, Feb 22 2009, Jörg Sommer wrote: Manoj Srivastava sriva...@debian.org wrote: On Sun, Feb 22 2009, Jörg Sommer wrote: Manoj Srivastava sriva...@debian.org wrote: On Sat, Feb 21 2009, Jörg Sommer wrote: 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. What does hook into apt-get mean? I use the hooks Pre-Install-Pkgs and Post-Invoke as provided by apt-get. What happens if I do a dpkg -i? Nothing. You have to update the branches by hand. And yet you are proposing to divert ucf? What do you suggest should happen when you run dpkg -i? What should etcgit do? etcgit should work whether or not it was aptitude, synaptic, apt-get, or dpkg which was used to install the package. The part I am worried about is whether the wrapper allows ucf to do its job; namely, ask the use what they want to do with any changes in configuration files. Based on your earlier email about calling ucf with FORCE_CONFOLD, that is not going to happen. Have you changed your mind about a) using force_confold? b) merging the upstream branch into the local branch (without using the merge policy of ours)? If you have not, either one of these would, in my opinion, would be an unacceptable bug that breaks installations. Now, you have also talked about not installing the wrapper -- which would be fine. If there is no wrapper around ucf, or f the wrapper does not use h FORCE_CONFOLD, I think the package will work I can explain why merging upstream changes into the local branch (unless you use the --strategy=ours)[1] The rest of the email is about issues raised due to the fact that I believed you were talking about a wrapper that gutted ucf; if we are talking about no wrapper, or the wrapper not using FORCE_CONFOLD, we are fine. But in this bug report you have to explain what broke. I please you, don't wait and tell it me now. Tell me what breaks when I divert ucf to ucf.etcgit and install this script as ucf: #!/bin/sh exec ucf.etcgit $@ Aha. You got rid of the FORCE_CONFOLD, and you are not merging the upstream into the local branch. This will work. [1] ,[ Old upstream version ] | # This can be A or B | behaviour_type=A | | # Other stuff ` ,[ User modified local config version ] | # This can be A or B | behaviour_type=B | | # Other stuff ` ,[ New upstream version ] | # This can be A or B | behaviour_type=A | | # Other stuff | | # Do not leave these uncommented unless behaviour type is A | Do_Type_A_Stuff=YES ` If changes from the upstream branch are applied to the local version, and not verified by a human; we will get a broken config. manoj -- Truthful, adj.: Dumb and illiterate. Ambrose Bierce, The Devil's Dictionary Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
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. signature.asc Description: Digital signature http://en.wikipedia.org/wiki/OpenPGP
Re: ucf: Diversion of /u/b/ucf by etcgit
On Sat, Feb 21 2009, Jörg Sommer wrote: 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 I don't see how you can get that. There is no file shipped with the package when you use ucf. Indeed, if there were files shipped in /etc in the package, you can't use ucf. The files given to ucf are often generated at install time -- and you have no way of knowing where they are located. What you are doing is to keep a static record of the very first file that etckeeper encounters -- and never, ever changing it, despite what the package maintainer wants as the new version. This does not seem like something anyone would actually want. 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. 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 -- which is to allow users to know there is a nerw version, and optionally use it. ucf will record that the upstream files md5sum is changed, but it will not actually record anything else about the upstream version (unless the threeway option is used). 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. ucf only changes the configuration file if the user asks it to. And the user, in your scheme, may never even know there is a file to be updated -- since you have effectively removed ucf functionality. This sounds more like etckeeper conflicts with ucf. I suggest you look more into how to integrate ucf mandated changes into etckeeper, rather than just gutting ucf. etckeeper needs to find out what the upstream version is, record that in the proper branch, and then ucf dot its stuff on the local branch, and record that. 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. manoj -- Once harm has been done, even a fool understands it. Homer Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
Manoj Srivastava sriva...@debian.org wrote:
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.
ucf only changes the configuration file if the user asks it
to. And the user, in your scheme, may never even know there is a file to
be updated -- since you have effectively removed ucf functionality.
This sounds more like etckeeper conflicts with ucf.
I suggest you look more into how to integrate ucf mandated
changes into etckeeper, rather than just gutting ucf.
From the little information I have about etcgit and etckeeper, it seems
to me that Manoj is right. It may, however, actually make sense to
divert (or change) ucf to make etc{git,keeper} usable with it: It would
have to commit the file to the correct branch of the repository (and
then update it's own database by doing something similar to what was
proposed originally).
Regards, Frank
--
Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
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
Re: ucf: Diversion of /u/b/ucf by etcgit
On Sat, Feb 21, 2009 at 11:09:52PM +, Jörg Sommer wrote: 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 $@ So this will leave the ucf db with a horribly incorrect view of the current state of the config file, and if the user ever removes etcgit, there'll be a real mess. 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. As a maintainer of packages that depend on ucf, I think that would be a reason to conflict with etcgit in order to spare users the pain of the issue above. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
On Sat, Feb 21 2009, Frank Küster wrote:
Manoj Srivastava sriva...@debian.org wrote:
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.
ucf only changes the configuration file if the user asks it
to. And the user, in your scheme, may never even know there is a file to
be updated -- since you have effectively removed ucf functionality.
This sounds more like etckeeper conflicts with ucf.
I suggest you look more into how to integrate ucf mandated
changes into etckeeper, rather than just gutting ucf.
From the little information I have about etcgit and etckeeper, it seems
to me that Manoj is right. It may, however, actually make sense to
divert (or change) ucf to make etc{git,keeper} usable with it: It would
have to commit the file to the correct branch of the repository (and
then update it's own database by doing something similar to what was
proposed originally).
I think the correct thing for the wrapper to do is
a) change branch to the upstram_version_branch, and commit the new
upstream.
b) Change back to the local branch
c) run ucf and let the user do their thing (replace, not replace, edit,
whatever).
d) Commit the result to the local_changed_branch.
The basic idea is _not_ to interfere with the real ucf, so the
user is asked, and the local file what ucf thinks the local file is,
and what the user actually wants there.
Apart from the whole FORCE_CONFOLD thing, the rest is basically
sound.
manoj
--
What I've done, of course, is total garbage. Willard, Pure Math 430a
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
On Sat, Feb 21 2009, Jörg Sommer wrote: 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. What does hook into apt-get mean? What happens if I do a dpkg -i? Also, there might be nothing shipped with the package. You can't hook into apt-get to get the file generated in the postinst -- since there might not _be_ a upstream version at all until the postinst is run. 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. Fair enough, This will work. 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. Hmm? save_original merge_with_current $ git checkout original file branch $ cp New File Destination $ git add Destination $ git commit $ git checkout local changes branch $ git merge original file branch Which is pretty horrendous, since it merges changes from the upstream branch into the local branch, which might break things, without asking the human. You also do not ask the human if they want to replace their local changes totally with the new upstream file -- which might have implemented the changes the user made in a different way. Then the real ucf can update it's database, but it should not touch the file I've put underneath /etc. It's export UCF_FORCE_CONFFOLD=1 ucf.etcgit $@ And the file has been changed udner the user, with the merge above, without the user ever being informed before the changes were committed. 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. Oh, you ask the use before you commit changes from the upstream branch before you actually change the local file You handle deleted files correctly? Since asking the user is the basic thing ucf does, unless you are asking the user, you are not re-implementing ucf. 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. I will consider adding a conflicts to the ucf package as well. manoj -- Sex is like air. It's only a big deal if you can't get any. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ucf: Diversion of /u/b/ucf by etcgit
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? 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? 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. If the user/maintainer decides to shoot themselves in the foot it is onething, but ucf should never set this as the default. run_real_ucf $@ rm $file.ucf-dist As the Debian policy requests, I write to you to tell you about my plan and ask for your approval. I think this should be discussed on -devel, not just between us. [1] http://git.debian.org/?p=users/jo-guest/etcgit.git;a=summary [2] http://git.debian.org/?p=users/jo-guest/etcgit.git;a=blob;f=ucf-wrapper;hb=HEAD manoj -- I hate dying. Dave Johnson Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
