Bug#533290: Do "etckeeper commit" at install time
Joey Hess wrote: > Thierry Carrez wrote: >> You're right. The user ignoring everything will get the first step >> committed as part of the next apt preinstall hook or the daily >> autocommit. So we don't really make it easier for him. I'll revert that >> change in Ubuntu so that both distributions behave the same from a user >> interaction perspective. And feel free to close this wishlist bug :) > > Acting as devil's advocate before closing it.. One reason a user might > care is if they're treating etckeeper as a quick and dirty backup > mechanism. If so, there'd be an expectation that as soon as it is > installed, you can begin to muck about with /etc and be able to revert > your changes. It could be suprising to find that there was no history to > revert to yet. Hmm... how about printing a message at the end of "etckeeper init" advising people to review the added file set and run "etckeeper commit" ? 1/ People explicitely installing etckeeper for quick backup would/should see the message 2/ It serves as a basic usage reminder 3/ People ignoring the message would get saved by autocommit at the end of the day -- Thierry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533290: Do "etckeeper commit" at install time
Thierry Carrez wrote: > You're right. The user ignoring everything will get the first step > committed as part of the next apt preinstall hook or the daily > autocommit. So we don't really make it easier for him. I'll revert that > change in Ubuntu so that both distributions behave the same from a user > interaction perspective. And feel free to close this wishlist bug :) Acting as devil's advocate before closing it.. One reason a user might care is if they're treating etckeeper as a quick and dirty backup mechanism. If so, there'd be an expectation that as soon as it is installed, you can begin to muck about with /etc and be able to revert your changes. It could be suprising to find that there was no history to revert to yet. -- see shy jo signature.asc Description: Digital signature
Bug#533290: Do "etckeeper commit" at install time
Joey Hess wrote: > Thierry Carrez wrote: >> How often do you think admins need to edit the added file set for >> security/clutter reasons ? > > I don't know, but I also doubt that it's common for anyone to need > access to the state of /etc at the instant etckeeper was installed, > rather than slightly later when something causes it to commit. You're right. The user ignoring everything will get the first step committed as part of the next apt preinstall hook or the daily autocommit. So we don't really make it easier for him. I'll revert that change in Ubuntu so that both distributions behave the same from a user interaction perspective. And feel free to close this wishlist bug :) Thanks, -- Thierry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533290: Do "etckeeper commit" at install time
Thierry Carrez wrote: > How often do you think admins need to edit the added file set for > security/clutter reasons ? I don't know, but I also doubt that it's common for anyone to need access to the state of /etc at the instant etckeeper was installed, rather than slightly later when something causes it to commit. -- see shy jo signature.asc Description: Digital signature
Bug#533290: Do "etckeeper commit" at install time
Joey Hess wrote: > Thierry Carrez wrote: >> etckeeper currently runs "etckeeper init" in postinst, as a fix for bug >> 505772. However this bug suggested to run both init and commit at >> install-time, in order to have a working setup just after the install >> command. >> >> This makes sense especially as the nifty "etckeeper uninit" allows you >> to undo both init and commit anyway. > > The reason I don't immediatly autocommit is because the user might want > to examine the files that etckeeper has added to version control and > remove some of them from it, for security or clutter reasons. They also > might want to update the VCS's ignore file. It makes sense to let them > do so before the initial commit. > > Of course, the commit will probably happen soon after install anyway, > either by the cron job, or by another apt run triggering it. Still, at > least this way the user has a window and doesn't need to do a tedious > uninit and reinit. Yes, it's obviously a trade-off between: * Having it up and running just after installation * Offering systematically the opportunity to review the added set My (final) goal for etckeeper is to make it a potential default install target (in Ubuntu), so that people can run it without even knowing it's there, and when they happen to need the history they can learn more about it and discover that it's been logging changes all along. That was the idea behind the daily autocommit. With that goal in mind, it makes sense for us to balance the tradeoff in the "up without any user interaction" direction. We make it easier for newbies, at the expense of making it slightly harder for experienced users (potential need to uninit + init + add + commit if you want to edit the set manually). However I'd perfectly understand if you prefer to balance that trade-off in the other direction in Debian :) I just submitted the idea, because the less delta we have the better it is for everyone. How often do you think admins need to edit the added file set for security/clutter reasons ? Cheers, -- Thierry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533290: Do "etckeeper commit" at install time
Thierry Carrez wrote: > etckeeper currently runs "etckeeper init" in postinst, as a fix for bug > 505772. However this bug suggested to run both init and commit at > install-time, in order to have a working setup just after the install > command. > > This makes sense especially as the nifty "etckeeper uninit" allows you > to undo both init and commit anyway. The reason I don't immediatly autocommit is because the user might want to examine the files that etckeeper has added to version control and remove some of them from it, for security or clutter reasons. They also might want to update the VCS's ignore file. It makes sense to let them do so before the initial commit. Of course, the commit will probably happen soon after install anyway, either by the cron job, or by another apt run triggering it. Still, at least this way the user has a window and doesn't need to do a tedious uninit and reinit. -- see shy jo signature.asc Description: Digital signature
Bug#533290: Do "etckeeper commit" at install time
Package: etckeeper Severity: wishlist Version: 0.37 Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch karmic etckeeper currently runs "etckeeper init" in postinst, as a fix for bug 505772. However this bug suggested to run both init and commit at install-time, in order to have a working setup just after the install command. This makes sense especially as the nifty "etckeeper uninit" allows you to undo both init and commit anyway. See attached patch for proposed implementation. Hope this helps, -- Thierry Carrez diff -Nru etckeeper-0.37/debian/postinst etckeeper-0.37ubuntu1/debian/postinst --- etckeeper-0.37/debian/postinst 2009-05-27 21:26:53.0 +0200 +++ etckeeper-0.37ubuntu1/debian/postinst 2009-06-16 09:56:57.0 +0200 @@ -77,7 +77,11 @@ # Fresh install. . /etc/etckeeper/etckeeper.conf || true if [ -n "$VCS" ] && [ -x "`which $VCS 2>/dev/null`" ]; then - etckeeper init || echo "etckeeper init failed; run it by hand" >&2 + if etckeeper init; then +etckeeper commit "Initial commit" + else +echo "etckeeper init failed; run it by hand" >&2 + fi else echo "etckeeper init not ran as $VCS is not installed" >&2 fi
