public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Christian Franke <Christian.Franke@t-online.de>
To: cygwin-apps@cygwin.com
Subject: Re: [ITP] etckeeper 1.18.17-1
Date: Sat, 2 Jul 2022 15:26:23 +0200	[thread overview]
Message-ID: <12bbc4c0-2fa8-401e-d0df-4cfcc028c463@t-online.de> (raw)
In-Reply-To: <20220629081214.zdphk3m744nfftkv@lucy.dinwoodie.org>

Adam Dinwoodie wrote:
> On Wed, Jun 29, 2022 at 09:55:10AM +0200, Christian Franke wrote:
>> Christian Franke wrote:
>>> ...
>> 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/etckeeper-git-init.sh
>> which triggers new initialization code in
>> /etc/postinstall/zp_zzz_etckeeper-postinstall.sh 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
> initiation.

Good point.


> 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!

  I now decided to leave this for later (or never). The package is new 
and if there are still issues during initialization, the messages should 
be visible on console.


  parent reply	other threads:[~2022-07-02 13:26 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
2022-07-02 13:02         ` Jon Turney
2022-07-02 13:26         ` Christian Franke [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=12bbc4c0-2fa8-401e-d0df-4cfcc028c463@t-online.de \
    --to=christian.franke@t-online.de \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).