[ITP] etckeeper 1.18.17-1

[ITP] etckeeper 1.18.17-1

[Christian Franke]

I would like to contribute etckeeper.

https://etckeeper.branchable.com/
https://repology.org/project/etckeeper/versions

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 \
https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.hint \
https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1-src.hint \
https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1-src.tar.xz 
\
https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.tar.xz \
https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.sha256

Tested with git. Only a few tests were done with hg.

Baazar is not fully supported yet as the pre-commit hook Python module 
is not included. The "bzr" command now fails on Cygwin as it still 
requires python2.7. Debian/Ubuntu moved to brz (breeze).

The current Cygwin Setup cannot automatically run the hook for 
'etckeeper pre-install'. A related patch is here:
https://sourceware.org/pipermail/cygwin-apps/2022-June/042076.html

As a workaround for now, 'etckeeper pre-install' could be run manually 
before starting setup. If not run, the 'etckeeper post-install' hook 
then also commits any pending changes done before setup, the "Package 
changes:" list in the log message is always empty and "Packages with 
configuration changes:" will not appear. The remaining functionality is 
not affected.

-- 
Regards,
Christian

Re: [ITP] etckeeper 1.18.17-1

[Adam Dinwoodie]

On Tue, Jun 28, 2022 at 12:58:23PM +0200, Christian Franke wrote:
> I would like to contribute etckeeper.
> 
> https://etckeeper.branchable.com/
> https://repology.org/project/etckeeper/versions
> 
> 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 \
> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.hint \
> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1-src.hint \
> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1-src.tar.xz
> \
> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.tar.xz \
> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.sha256
> 
> 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
maintainer.

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.

Adam

Re: [ITP] etckeeper 1.18.17-1

[Christian Franke]

Adam Dinwoodie wrote:
> On Tue, Jun 28, 2022 at 12:58:23PM +0200, Christian Franke wrote:
>> I would like to contribute etckeeper.
>>
>> https://etckeeper.branchable.com/
>> https://repology.org/project/etckeeper/versions
>>
>> 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 \
>> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.hint \
>> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1-src.hint \
>> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1-src.tar.xz
>> \
>> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.tar.xz \
>> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.sha256
>>
>> 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 :)

Thanks for review. I did various test, also with a local build of setup 
which includes my patch to automatically run 'etckeeper pre-install'.


> 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
> maintainer.

I definitely will do this.


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

-- 
Regards,
Christian

Re: [ITP] etckeeper 1.18.17-1

[Christian Franke]

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/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.

-- 
Regards,
Christian

Re: [ITP] etckeeper 1.18.17-1

[Adam Dinwoodie]

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/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.

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!

Re: [ITP] etckeeper 1.18.17-1

[Jon Turney]

On 28/06/2022 11:58, Christian Franke wrote:
> I would like to contribute etckeeper.
> 
> https://etckeeper.branchable.com/
> https://repology.org/project/etckeeper/versions
> 
> 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 \
> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.hint \
> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1-src.hint \
> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1-src.tar.xz 
> \
> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.tar.xz \
> https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.sha256
> 
> Tested with git. Only a few tests were done with hg.

Thanks.

Since you didn't mention it in your ITP, I checked the license, which is 
'GPL-2.0-or-later'.

I added this to your packages.

Re: [ITP] etckeeper 1.18.17-1

[Jon Turney]

On 29/06/2022 09:12, Adam Dinwoodie wrote:
> 
> 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

Oh no, they share their misery: I sometimes receive emails virtually 
written in green ink moaning about how long installing everything takes.

The solution to that is probably to remove the option to install 
everything from setup, which has sometimes been mooted (or at least put 
it behind a command line option).

Re: [ITP] etckeeper 1.18.17-1

[Christian Franke]

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.