oernc / oesenc
aw-bib opened this issue · 7 comments
There seems to be some confusion in sources and the two plugins required for o-charts.
Once openplotter-settings added the necessary sources the following packages become available:
opencpn-plugin-oerncopencpn-plugin-oesenclibsglockoernc-pioesenc-piopencpn-sglock-amd64
oernc-pi, oesenc-pi and opencpn-sglock-amd64 are drawn from LP-PPA-opencpn-opencpn-bionic and the former two require the latter one.
opencpn-plugin-oernc, opencpn-plugin-oesenc and libsglock come from free-x.de where the former two requite the latter one.
It is not really clear which plugins should be installed or if they are just dupes with different names. (opencpn-plugin-* at least seems nearer the other stuff than *-pi, however it seems OpenPlotter settings go for the last option.)
Note further that one could tell the package manager to install either set, but if libsglock is installed for some reason, and one opts for oesenc-pi one ends up with an error that the required package opencpn-sglock-amd64 is trying to overwrite a file that is provided by another package and one ends up with a brocken package.
Similar requests for upgrade/downgrade also happen for opencpn itself, which is also provided by more than one source.
Found on Debian 10, using OpenPlotter Settings 2.2 trying to replicate the setup of a raspberry pi 4 running OpenPlotter 2.2 as well.
isRelatedTo: #1
opencpn-plugin-oernc and opencpn-plugin-oesenc are completely wrong and should not be anywhere.
Those names was an old mistake of OpenCPN maintainers naming the packages. Official packages are oernc-pi, oesenc-pi.
@free-x
The problem here is that we use free-x.de repository because there is a working and maintained version of XyGrib for raspberry but there are also other packages like opencpn or opencpn plugins that repo owners use to test or develop.
This is why we use Debian preferences to give priority to PPA repos: https://github.com/openplotter/openplotter-settings/blob/master/openplotterSettings/data/sources/99openplotter
The problem here is that opencpn-plugin-oernc and opencpn-plugin-oesenc only exist in free-x.de repo and they will have always preference and will be installed if anyone tries that. The easy solution is removing them if possible because they are obsolete.
moin,
i found that my name schema for these packages is much more clearer.
you can of course ban my packages
Package: opencpn-plugin-oe*
Pin-Priority: : -1
packages like opencpn or opencpn plugins that repo owners use to test or develop.
It's production ready packages.
I do not find it kosher to use ubuntu packages under debian. Because of different compilers, libraries, etc
Hi free-x, thanks for answering.
I though you were using those old names created by mistake. You are or course free to rename any package but if you have plans to distribute publicly those packages changing the name of official packages is not a good idea.
OpenCPN has been using Ubuntu PPA repos in Debian for long time without problems. But this is going to change soon. OpenCPN will become an official Debian package soon and plugins will be managed directly by OpenCPN so PPA will be progressively deserted:
oernc-pi and oesenc-pi will be the first ones to be migrated to the new plugin management system where no repos will be involved, so even oernc-pi and oesenc-pi will become obsolete soon.
@sailoog thanks for clearing up this naming issue.
I have to admit, however, that I agree with @free-x wrt the naming. Indeed his package names are a lot clearer which is the reason why I ran into this issue in the first place. *-pi sounds a lot like for raspberry pi only which could not be as it's the amd64 repo etc. OTOH the free-x packges sort so neatly into opencpn.
OTHO I perfectly agree with @sailoog that renaming official packages is probably not the best of ideas. So if there is something official I'd suggest to stick to it.
@sailoog I like the idea of OpenCPN to become a real package in Debian. IMHO that's great news. I also admit that I really hate adding unofficial sources at all. I tend to leave this to the Ubuntu-people.
So becoming an offical part of debian will sort out quite a few issues I had in the past as Debian is not Ubuntu. Playing with OpenCPN for a while now on Debian (needless to say: stable) I got used to some strange issues to happen, broken packages popping up of nowhere an update that is not possible anymore as some libs changed, and quite a bit of clean up work. Basically, I still treat OpenCPN a bit like don't touch and even strongly considered moving it to some virtual box till it becomes stable on this front. Of course I could start to compile from source, which I do with some other tools, but due to the plugins required this seems to be a major endeavour.
However, I also admit I do not really like the circumvention of the package management you suggest by "we invent our own thing" that much. Note that using the package management can save quite a few clicks in the OpenPlotter setup GUI. Don't get me wrong: it is nice if you're new and don't know your way around and/or you don't know a thing about Linux. It really helped me to sort out all this raspberry pi black magic (that actually doesn't exist if you know Linux a bit ;) And adding the proper sources I can probably drop compiling xygrib.
So, IMHO apt update; apt upgrade together with apt install is so nice a feature, really no need to reinvent. I'd really like to update, especially the little one, that way instead of dd some images every other week. Hope, that this stays however you handle plugins. :)
I agree with both of you, opencpn-plugin-xxx is obviously the correct way but we realized this when it was too late and the xxx-pi had spread too much. We were forced to keep xxx-pi name or people would never update their installed versions, you know the apt update stuff... :)
Fortunately this will stop being important because both formats will disappear soon. Having OpenCPN as official debian package makes a plugin managed system mandatory because plugins developers will not become debian packages maintainers at all but especially because a centralized and managed plugin system will make possible sharing plugins with other linux distributions and platforms. Do not forget that maintaining a multi-platform software is a pain (all linux distributions and flavors, Windows, Mac and Android).
I think we also need the openplotter-opencpn-installer to make life easier to linux newbies, as you pointed, and to have a flexible system to integrate easily big changes like the future opencpn plugin managing system and correct mistakes like this opencpn-plugin-xxx/xxx-pi issue.
apt stuff will be always there for advanced users or brave newbies ;)
Fortunately this will stop being important because both formats will disappear soon. Having OpenCPN as official debian package makes a plugin managed system mandatory because plugins developers will not become debian packages maintainers at all but especially because a centralized and managed plugin system will make possible sharing plugins with other linux distributions and platforms. Do not forget that maintaining a multi-platform software is a pain
when i first read about "managed" plugins, my first wish was to call "Haleluja". But after that I realized what consequences this could have. The package management of distribution is being completely overridden. All the security mechanisms are overridden.
Maybe I'm exaggerating, but this is how a horror scenario looks for me: The binaries like oeserverd are simply installed by non-privileged users into a subdirectory of user and are started from plugin ( classic backdoor ).