Bug#849754: RFS: guerillabackup/0.0.0-1

[halfdog <me@halfdog.net>]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "guerillabackup"

* Package name    : guerillabackup
  Version         : 0.0.0-1
  Upstream Author : halfdog
* URL             : https://github.com/halfdog/guerillabackup
* License         : LGPL-3
Section           : misc

It builds those binary packages:

  guerillabackup - resilient, distributed backup and archiving solution

To access further information about this package, please visit the following URL:

https://mentors.debian.net/package/guerillabackup


Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/g/guerillabackup/guerillabackup_0.0.0-1.dsc

More information about guerillabackup can be obtained from
https://github.com/halfdog/guerillabackup

Changes since the last upload:

  * Initial packaging of guerillabackup (Closes: #849714)


As also stated in comment to https://mentors.debian.net/package/guerillabackup
to avoid reviewers wasting time searching for dirty little package
secrets, here are some pointers to things, I had problems with,
when creating the package. Reviewers might disagree with my proposed
solution, any feedback is very welcome!

* Upstream Debian file templates: to support building of native
  packages using only the upstream source, Debian package files
  and build instructions are included already in upstream. To
  avoid duplication of them when not (yet) needed, they are copied
  within "rules" in target "override_dh_auto_configure"

* (Re)starting units on upgrade: As stated in documentation, two
  services can be used also from commandline (on demand) or as
  non-root user, depending on end user use cases. Thus it is intended,
  that the two systemd units are not enabled by default. Also
  a user may start them manually without enabling them. With upgrade
  following problem may arise: with standard debhelper means it
  was not possible to
  1) stop all running units and
  2) after update start only those, that were running beforehand.
  Solution:
  1) do not use debhelper for stopping/starting of units,
  2) find out in "prerm" which units are currently running, stop them and
  3) in "postinst" start only those, that were running in step 1)

* Use of .pyc files: As I do not fully understand the consequences
  of using .pyc files, especially in conditions where backup might
  be more important, e.g. when disks start already failing and
  py/pyc files might fall out of sync, I decided not to use them
  until I understand the possible risks. As codebase is very small
  and program is long-running, overhead from JIT-compiling should
  be not an issue.

Regards,
hd