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

On Tue, Jun 28, 2022 at 12:58:23PM +0200, Christian Franke wrote:
> I would like to contribute etckeeper.
> etckeeper-1.18.17-1.hint:
> category: Utils
> requires: bash coreutils grep sed
> sdesc: "Store /etc in git or mercurial"
> ldesc: "Etckeeper is a tool to let /etc be stored in git or
> mercurial.  It hooks into Cygwin Setup to automatically commit changes
> made to /etc during package upgrades.  It tracks file metadata
> (permissions, owner, group) that version control systems do not
> normally support."
> Package for review:
> wget -r -nH --cut-dirs=2 \
> \
> \
> \
> \
> Tested with git. Only a few tests were done with hg.

LGTM!  I've not tested the actual function, but the packaging looks
sound, and I trust etckeeper enough that if the packaging is sound I'm
happy the rest will follow :)

I do wonder if it's worth trying to submit your patches upstream; they
seem like the sort of thing the upstream project might be interested in
taking, and it minimises the amount of work you have to do as a

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.


  reply	other threads:[~2022-06-28 17:41 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 [this message]
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
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).