public inbox for
 help / color / mirror / Atom feed
From: Adam Dinwoodie <>
Subject: Re: [ITP] etckeeper 1.18.17-1
Date: Wed, 29 Jun 2022 09:12:14 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Jun 29, 2022 at 09:55:10AM +0200, Christian Franke wrote:
> Christian Franke wrote:
> > Adam Dinwoodie wrote:
> > ...
> > 
> > > I'm also vaguely pondering whether it's worth adding git as a
> > > dependency.  That's not strictly right, since etckeeper doesn't *need*
> > > git, but it's going to be the use case for 99.9% of users, and in the
> > > absence of Cygwin having a "recommends" style dependency, just adding
> > > git seems like it might be sensible.  But I'm far from convinced there.
> > 
> > I'm also not sure and decided to add no git dependency. 99.8% of the
> > users considering to install etckeeper may already have git installed
> > :-)
> > 
> > The Debian package does not use "rec" but "dep (git or hg or brz or
> > darcs)" which defaults to git.
> > If git is installed, the Debian postinst script runs 'etckeeper init &&
> > etckeeper commit' on fresh installs. I decided to leave this to the
> > user.
> > 
> A possible simple extension which would allow the user to choose between
> manual or automatic installation+initialization:
> Provide an optional package, for example "etckeeper-git-init", which depends
> on etckeeper+git and only contains /etc/postinstall/
> which triggers new initialization code in
> /etc/postinstall/ via some file in
> /var/cache/etckeeper. This code performs 'etckeeper init && etckeeper
> commit' if and only if VCS=git is selected and /etc/.git does not exist.

Honestly, I suspect it's not worth the effort of doing things like that.
As you say, 99.8% of users who might be interested in using etckeeper
are going to be people who already have a good idea what they're doing
and will be able to work it out for themselves.

Thinking about it some more, I'm also mildly concerned about the small
but non-trivial proportion of users who blithely install every package
available on Cygwin, which I don't think is going to be an issue for
more-or-less any other *nix distribution.  I don't normally think it's
worth doing much to actively catering for those users -- I'm generally
of the opinion that they're making their own misery -- but in this case
automatically starting etckeeper would be a potentially significant
impact, and for the sake of both their lives and yours, I suspect it's
best to just leave etckeeper as something that requires manual

That said, if you're keen to set up that optional package, I definitely
don't think it's a bad idea; "it wouldn't be worth the effort to me"
doesn't mean you shouldn't do it!

  reply	other threads:[~2022-06-29  8:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-28 10:58 Christian Franke
2022-06-28 17:41 ` Adam Dinwoodie
2022-06-28 21:09   ` Christian Franke
2022-06-29  7:55     ` Christian Franke
2022-06-29  8:12       ` Adam Dinwoodie [this message]
2022-07-02 13:02         ` Jon Turney
2022-07-02 13:26         ` Christian Franke
2022-07-02 12:34 ` Jon Turney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).