Reinhard challenged me offlist to look at whether boxbackup would actually be more maintainable with dh than with its current use of debhelper.
Here are things I noticed that I wouldn't have to think about with dh. The package may be correct, but if I were trying to maintain the package I'd need to evaluate all of these. These are more or less just as complicated with dh, but the entire point is that I only need to remember one complicated thing rather than lots. * The package uses findstring rather than filter when searching DEB_BUILD_OPTIONS. I know that filter is preferred I think because findstring will do substring matches. I need to remember why that's bad for DEB_BUILD_OPTIONS and consider whether it's a bug. * What's with the debug DEB_BUILD_OPTION. I'd need to make sure that by default -g is included per policy. * It doesn't look like noopt is explicitly handled. Does dpkg-info.mk do that for me? I can't remember; better go look. It's probably going to be a combination of dpkg-buildflags, the makefile fragment, configure's handling of environment variables, etc. Yeah, it's just as complicated with dh, but I have high confidence dh gets this right. * It looks like the version and configure handling are a little prickly in this package; I get the impression that the configure script may not be entirely well behaved. Or perhaps it's just maintainer style. With dh that would stand out one way or the other and be obvious. *There's an init script and a systemd unit. That'll break when this goes to compat 11 or 12. (Well really that situation's going to be broken with compat 11 anyway), but getting the advantages of the systemd handling in compat 12 would be better with dh. * As Simon pointed out I'd need to go check the ordering of all the debhelper calls. I'm fairly sure this is correct, but it would be nice to not need to worry about that. So, yes, this package would be much more appealing to third parties who need to look at it after the dh conversion. I fully acknowledge that conversion is real work. Each of the bullet points I enumerate above and several others would need to get checked. We've talked about how when doing such conversions we should check and make sure we get identical binaries out. Here I'm not sure that's right. I'm not sure the existing buildflag, debug, optimization and stripping behavior is right. So, the conversion might be harder to the extent I'm needing to check correctness of the existing packaging. Am I jumping up and down to go do that work on this package? Absolutely not. do I hope whoever adopts it does that work? Yes.
