app-backup/btrbk: add versions 0.23.2 and 9999

[candrews]

btrbk is a backup tool for btrfs subvolumes, taking advantage of btrfs specific capabilities to create atomic snapshots and transfer them incrementally to backup locations via ssh.

https://bugs.gentoo.org/show_bug.cgi?id=564780

[candrews]

@gentoo/proxy-maint How's this look?

[gktrk]

The correct license is GPL-3+

[gktrk]

@gentoo/proxy-maint

[gktrk]

Is there a reason why we prefer manual installation over something like:
emake DESTDIR="${D}" DOCDIR="${D}/usr/share/${PF}" install

[candrews]

@gktrk good point, this change really reduces the number of lines / complexity of the ebuild and improves maintainability.
Here's what I'm doing now:

src_install() {
        emake DESTDIR="${D}" DOCDIR="/usr/share/doc/${PF}" install
}

I compared the output of equery files btrbk before and after this change. They're identical except for 2 small differences:

• The ChangeLog isn't installed by the Makefile - I don't think this is worth doing in the ebuild, but I asked upstream to make this change: Include ChangeLog in install-doc digint/btrbk#95
• The ebuild was installing the scripts in /usr/share/btrbk instead of /usr/share/btrbk/scripts (which the Makefile does). Doing what upstream does is the way to go.

[candrews]

@digint do you want to be included as a maintainer in metadata.xml?

[digint]

Yes you can add me as a maintainer.

Regarding the Makefile: are the systemd unit files copied to the correct place when using emake install rather than systemd_dounit ? If so, I agree that it's much cleaner this way.

You might also consider depending on sys-apps/pv. This is only used for the --progress option and rate_limit config option, but some people (on the debian package) complained about this missing dependency.

@candrews I'm releasing btrbk-0.23.3 later tonight (small bugfix, also adding missing ChangeLog), yell if there's something missing.

[candrews]

@digint,

Yes you can add me as a maintainer.

Excellent, I've updated metadata.xml accordingly.

Regarding the Makefile: are the systemd unit files copied to the correct place when using emake install rather than systemd_dounit? If so, I agree that it's much cleaner this way.

In both cases, the files are copied to /usr/lib/systemd/system which is probably almost always right. Thanks for point this out - I've changed the ebuilds to pass SYSTEMDDIR="$(systemd_get_systemunitdir)" to emake so that the path is always right :-)

You might also consider depending on sys-apps/pv. This is only used for the --progress option and rate_limit config option, but some people (on the debian package) complained about this missing dependency.

I added a use flag to toggle this dependency - I think that approach makes sense.

I'm releasing btrbk-0.23.3 later tonight (small bugfix, also adding missing ChangeLog), yell if there's something missing.

Thanks!

[digint]

@candrews thanks, I can confirm it working at my place.

[gktrk]

Merge in 932c16f. Thanks!

I've made the following changes before merge:

• Removed extra empty line at the end of metadata.xml
• Mangled the commit message summary line slightly