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
Attachment:
signature.asc
Description: PGP signature