Control: owner -1 ! Ok, finally found time \o/, but did not have enough to complete the review :-(
(The review is based on the package from mentors uploaded 2020-09-10 19:38.) Not yetreviewed: dep3-headers on patches, d/changelog and d/copyright as Alec is actively working on those (as per private mail) Two remarks: - d/changelog You could bumpt the timestamp on the changelog from time to time, though ;-): dch -r "" is a nice trick ;-) - (nitpick) d/changelog Please be consitent on the Closes: Stancas - Line 2 says Closes: 948702, line 3 says Closes #962213. Please use either with '#' or without '#' … just for my eyes to relief… d/control: - you can drop opencpn-plugins; I guess this is for people who installed before Debian had the package. OK to keep the Break/Replace until opencpn has been released with a Debian stable release. (I cant check if the version constraint is right, because "<<" is strictly earlier, that means 4.8.6~20180801.8d20a06+dfsg.1 was the first version with an empty plugins package?; It would be safe to us << 4.8.8~, though. Update: #917561 seems to indicate that this change was actually introduced in 4.8.8+dsfg.1-1 -- so the above restriction would be too old…) - is wx3.0-i18n really required to run opencpn? Maybe Recommends is enough? - opencpn recommends binutils. Can you say why, its a bit unusual for non-development applications. d/opencpn.install and d/rules… There are some issues, I'll follow up later on those, probably with a patch/MR (hint to update salsa, see below). d/clean - NSIS.template.in is appearantly recreated during build, it should be deleted via d/clean. (Then debuild twice will work, too) d/rules: In the override - instead of making the links to the licenses, you could use dh_links(1) multiarch: - the plugin *.so are not installed in an multiarch aware path. nitpicks: - theres a trailing space in README.source (use wrap-and-sort(1) ;-)) Wishlist: - please enable salsa-ci on the packaging repo… (wishlist items related to README.Debian) - I see docs are not packaged for privacy reasons. Could they be when the docs being patches (not an unseen in Debian)? (e.g I hate it if the docs are not matching the version I have installed, as often the docs for the newer version won't apply well enough) - (as you are upstream-involved, this is probably easy to fix on your side:) The plugin code could also look into alternative directories… - The /usr/share/ hierachicy is reserved for packaged stuff, so encouraging users to copy stuff there is a bit meeeh; it can create problems when e.g a new package provides this file. - So probably /usr/local/… or /opt/… would be a better recommendation. - Additionally, when users should be able to install plugins without being root, something like $HOME/.local/… (not sure if this is consenus in Debian, though) - dont forget to push to salsa…;-) -- I can also review from there (only for the final upload I prefer to do with a package from mentors, just to make sure that I upload the right orig.tar.) Plus I can offer MRs instead of snarky comments ;-) -- tobi
signature.asc
Description: PGP signature