Re: Do we want to Require or Recommend DH
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.
Reply to: