Bug#965363: Fwd: Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi Tobias,
Here we go:
On 12/09/2020 16:28, Tobias Frost wrote:
> Control: owner -1 !
>
> Two remarks:
> - d/changelog You could bumpt the timestamp on the changelog from time to time, though
> ;-): dch -r "" is a nice trick ;-)
Indeed, thanks! Tried now, will need to to it again.
> - (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…
Fixed
> d/control:
> - you can drop opencpn-plugins; I guess this is for people who
> installed before Debian had the package.
Not really. It's about an old version which seemingly has existed in
Debian about 2015 (I find the traces in the salsa git log for opencpn.
Still drop? (leaving for now)
> 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…)
Again, this is (was?) about the traces I found in the salsa log. Shall
we drop the Breaks/Replaces? Or update to the correct value << 5.0.0+dfsg?
Certainly happy to drop, these things are messy and nice to get
rid of. Your thoughts? (leaving for now)
> - is wx3.0-i18n really required to run opencpn? Maybe Recommends is
> enough?
Recommends: is indeed enough. Fixed (*how* did you catch that one?
Tooling? Experience?)
> - opencpn recommends binutils. Can you say why, its a bit unusual for
> non-development applications.
It's about some built-in crash-reporting stuff which uses addr2line.
> 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).
OK.
> d/clean
> - NSIS.template.in is appearantly recreated during build, it should be
> deleted via d/clean. (Then debuild twice will work, too)
Indeed, thanks! Fixed.
> d/rules:
> In the override
> - instead of making the links to the licenses, you could use
> dh_links(1)
Problems:
$ man dh_links
No manual entry for dh_links
$ apt-cache search dh_links
$
Google doesn't give anything meaningful either.
> multiarch:
> - the plugin *.so are not installed in an multiarch aware path.
This is actually on purpose. I read the multiarch docs like multiarch
paths are only applicable to libraries i. e., there are no multiarch
applications. opencpn is an application, we cannot have multiple
architectures in $PATH, and hence the plugins which are an integrated
part of the application lives in /usr/lib/opencpn rather than the
multiarch path.
Or?
> nitpicks:
> - theres a trailing space in README.source (use wrap-and-sort(1) ;-))
Fixed (using vim...)
> Wishlist:
> (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)
I don't follow you here... This should really be fixed upstream, by an
easy-to-use option for users to download the docs (the download is
available upstream). However, I don't think it's reasonable to fix it
downstream.
Basic problem is that the docs are generated using a wiki system which
just havn't (and cannot have) sources which are public. Please don't ask
me why this system is used...
> - (as you are upstream-involved, this is probably easy to fix on your
> side:) The plugin code could also look into alternative directories…
It actually already does. It's perfectly possible to create
.deb-packaged plugins, and there are plenty around -- this is the way
plugins have been packaged for Debian/ubuntu since long. In the upstream
bugs (which you seem to have skimmed to in some cases?), these are
referred to as legacy plugins.
> - 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)
There are just so many problem here. In Fedora, packages are explicitly
forbidden to write anything under /home for good reasons. I don't think
Debian is or should be different. But, see above, .deb packages work
out of the box.
I have pushed a new version to mentors, with fixes above. The patches
and d/copyright are fixed to the point that I don't know what more to
do. I understand that it is possible to simplify d/copyright in some
cases, but trusting you to judge which.
Cheers!
--alec
Reply to: