from home page etckeeper is a collection of tools to let /etc be stored in a git, mercurial, or bzr repository. It hooks into apt (and other package managers) to automatically commit changes made to /etc during package upgrades. It tracks file metadata that revison control systems do not normally support, but that is important for /etc, such as the permissions of /etc/shadow. It's quite modular and configurable, while also being simple to use if you understand the basics of working with revision control. Reproducible: Always
Reassigning back to maintainer-wanted since Ingmar has retired as a Gentoo developer (#202413).
Created attachment 180553 [details] Proposed ebuild fot etchkeeper with patch on original sources I patch etckeeper sources to fit it. I'm guessing that sys-apps/etckeeper with sys-apps/metastore would be a good location. Both ebuilds get sources by a git repository. ebuild of sys-apps/metastore is here : http://bugs.gentoo.org/show_bug.cgi?id=219296
Created attachment 180555 [details, diff] patch used by etckeeper ebuild Patch used by etckeeper ebuild
Setting EGIT_FETCH_CMD="git clone --bare" in the ebuild might work (I'm not sure about that, though).
Sorry, wrong bug. That text was intended for the metastore bug. Getting metastore works with the change to the git fetch code, but the etckeeper patch doesn't apply.
The etckeeper is changing quickly, and patch was for etckeeper 0.26. It should be rebuild.
I have an ebuild for 0.34 in my overlay (layman -a luke-jr), but it does have one slight bug I don't really care to address yet: bzr support is compiled/installed even if not wanted.
Created attachment 211582 [details] ebuild for etckeeper 0.41 using git, based on ebuild from sYdRo This ebuild uses current HEAD (tag 0.41) of etckeeper. To make it more stable I didn't let it point to HEAD, but let it checkout tag 0.41 so that this isn't an etckeeper-9999.ebuild. During my tests bash-completion install didn't work. I fixed that issue. The ebuild code for incorporating the patch was fixed, too (didn't work on my system).
Created attachment 211584 [details] updated patch for etckeeper-0.41
Created attachment 211585 [details] same ebuild, but removed obsolete debugging output Sorry. I thougt I already removed this line...
shouldnt we DEPEND on git by default?
(In reply to comment #11) > shouldnt we DEPEND on git by default? Interesting point. I think this would be better. It doesn't matter on install, because the install needs git anyway. But it would be cleaner. We then should depend on git if the corresponding use flag is set or none of the other rcs is set per use flag. Because you could use etckeeper without git.
In any circumstance, that should be RDEPEND, not DEPEND.
Created attachment 238309 [details] new version
Created attachment 260211 [details] version bump; ebuild now using EGIT_COMMIT Version bump from 0.47 to 0.51. Since EGIT_TREE is deprecated I now use EGIT_COMMIT, as suggested by the nice warning. Seems to work.
Created attachment 260218 [details] version bump; ebuild now using EGIT_COMMIT; removed metastore dependency Because metastore seems to be unmaintained I had a look if it is still needed after posting my new ebuild. Seems that is was never needed for the ebuilds posted here. Since 13 Mar 2008 (Version 0.13, see http://git.kitenet.net/?p=etckeeper.git;a=commit;h=a9ce9965c06571a57522106691dac2f9892125ba) metastore is not needed anymore.
Created attachment 264207 [details] version bump Changes: Rewrote 50git-rm to avoid using git ls-files, and thus avoid encoding problems with filenames
Created attachment 268141 [details] version bump; bug fix This is etckeeper-0.53.ebuild. Changes: Before releasing version 0.51, the author of etckeeper moved it out of /usr/sbin into /usr/bin. This broke automatic pre/post-inst emerge hook script, and etckeeper didn't get invoked during emerges. It is fixed now.
Created attachment 268143 [details, diff] etckeeper-gentoo-0.53.patch for etckeeper-0.53.ebuild
this ebuild does not respect EPREFIX. * QA Notice: the following files are outside of the prefix: * /etc * /etc/bash_completion.d * /etc/bash_completion.d/etckeeper * ERROR: sys-apps/etckeeper-0.53 failed: * Aborting due to QA concerns: there are files installed outside the prefix
tried with USE=-bash-completion, it doesn't install any files on prefix at all.
Created attachment 287769 [details] updated ebuild * use of git-2 bash-completion-r1 * EGIT_COMMIT="${PV}" * app-portage/gentoolkit (non-)versionning * use of dobashcomp * uncommented dodoc * ${PN} for epatch seems fine with 0.56 (patch still needed though)
Created attachment 293841 [details] Updated to etckeeper 0.58 I've updated the ebuilds here to 0.58, fixed them to work with current gentoolkit, and added a significantly more optimized package lister for Portage (only).
Created attachment 293843 [details, diff] Updated patch
Just wanted to throw this idea out here... it would be seriously awesome if Portage could be told to use an *alternate root* for config-protected directories (and not protect within that root), so we could have an unmodified-configs branch, and just let git merge that to the real /etc ;)
(In reply to comment #25) > Just wanted to throw this idea out here... it would be seriously awesome if > Portage could be told to use an *alternate root* for config-protected > directories (and not protect within that root), so we could have an > unmodified-configs branch, and just let git merge that to the real /etc ;) +1 to that
Created attachment 310435 [details] etckeeper-0.62.ebuild Updated ebuild - dropped git-2 eclass - use generated tarballs - updated patch to add gentoo specific things - added python-dep for bzr - dropped postrm, postinstall doing things in /etc (never touch a running system!) - many more changes Has been added to sunrise.git, after review you can pull it through sunrise-overlay.
Created attachment 310437 [details, diff] etckeeper-0.62-gentoo.patch
Created attachment 310439 [details] bashrc
Created attachment 310441 [details] bashrc I hope you guys don't mind when I clean up this bug report a bit. Especially because that "echo "source /etc/portage/etckeeper" >> ${ROOT}/etc/portage/bashrc" line is very bad. We should not modify those user-configuration files at all. Thanks for your work. You can easily update/enhance this package by joining #gentoo-sunrise now.
Package will be available after review here: http://git.overlays.gentoo.org/gitweb/?p=proj/sunrise-reviewed.git;a=tree;f=sys-apps/etckeeper
I am running etckeeper (thanks to all the guys above) since 0.34 without any issues on 3 amd64 machines. Now it is version 0.62 from sunrise overlay, which I have since the first day it appeared in sunrise. Also no problems. Maybe it is time to merge it in the main tree? BTW, latest upstream version is 0.63 now.
0.63 is already in sunrise, just waiting for review.
(In reply to comment #33) > 0.63 is already in sunrise, just waiting for review. Great to hear that. Thanks for your work.
16 Jun 2012; Julian Ospald <hasufell@gentoo.org> +etckeeper-0.63.ebuild, +files/etckeeper-0.63-gentoo.patch, +files/bashrc, +metadata.xml: initial import with Manuel Rüger wrt bug #216114
