debian directory improvements
slavkoja opened this issue · 3 comments
Hi,
i tried to build debian package on current testing (buster) and it provides empty binary package. After small investigation, i have some suggestions to improve it:
Make its build dependencies to debhelper>10 (it is available in stable and via backport on oldstable too and it depends on dh_autoreconf, which is needed) and add bats into it (all test fails without it) into debian/control:
Build-Depends: debhelper (>= 10~), bats
Do not use native format, it is not recommended and it is a problem with it, if upstream (you) provides debian directory, you can read more at mentors, then i suggest to change debian/source/format to:
3.0 (quilt)
This requires to add debian's version into debian/changelog, eg.:
netcalc (2.1.4-1) unstable; urgency=medium
And finally, please do not install ipcalc symlink and remove conflict with it. From my point of view (as exmaintainer some official debian packages) it is too intrusive to force people to uninstall package, which can coexistent without any problems (i did it internally).
I forget to mention, that call to dh_autoreconf have to be added into debian/rules:
%:
dh $@ --with autoreconf
Packaging preferences seem to be different for every Debian developer I talk to. The native form we use here is what is also used by the Inadyn project, and the pros and cons of native vs quilt were discussed at length there. So I'm going to deny your request to change to quilt.
The other points you bring up are interesting though:
- Step debhelper version, yup that's a big todo for most of my projects
- Symlink to ipcalc, the best way I guess is to provide a separate package for it. E.g. netcalc-ipcalc_foo.deb
- Regarding autoreconf in rules, thanks!
Ad ipcalc, IMO it is best to manage it as alternative (via update-alternatives) but without cooperation with ipcalc maintainer, you will need to bother with with dpkg-divert and i never tried it for this. If someone want to use netcalc as ipcalc, it can simple make alias for it ;-)
Ad native/quilt, the main difference is, when package maintains someone other than you. In quilt type package, when i do source update automatically via uscan, my debian directory changes are retained and relevant things are updated by uscan. With native packages i need to reapply all my changes in debian directory manually after any update. AFAIK this is main reason, why quilt type is recommended, while it is a bit complicated to work with it for accidental/unexperienced users. It is, of course, your decision, but if you want, you can see and try it from my personal repo https://debs.slavino.sk/pool/main/n/netcalc/