Replies: 17 comments 18 replies
-
|
The patch, proposed by Nohal, works to support legacy packaged plugins inside OpenCPN 5.8.2 That will make easy the update for a rpm based distribution, keeping previous user's data |
Beta Was this translation helpful? Give feedback.
-
Agreed. What could be done is something very different, based on that rpm packages installs tarballs in a fixed location under /usr. In this scenario we could add some support which automatically adds these tarballs to the catalog (the metadata is bundled in the tarballs, making this possible). Another tweak needed is the download url which is this case would be a The basic underpinnings for this is a kind of "dynamic" catalog which can be modified depending on metadata available by other means than the plugins project. I'm on it, but with limited time. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Alec To give you some informations about what does a rpm installation of OpenCPN 5.8.2 updating a previous installation of OpenCPN 5.6.2 Besides this inside /usr/bin/ I can find opencpn (and for o-charts : oexserverd and libsgllnx64-*.so ) inside /usr/lib/udev/rules.d/98-sglock-ocpn.rules This seems to be identical with what does a debian installation with the Plugin Manager (I looked at the content of the tarballs provided by cloudsmith for debian) All the installed plugins work out of the box and the user's file are correctly written in the right place That means that with the Pavel's patch applied to opencpn evrything is OK for me and works like inside Debian with the Plugin Manager I survey the arrival of new versions of the plugins and provide the updates of the plugin rpms... that's not very difficult since there are little modifications to bring to the spec files I didn't see any problem with the installed plugins (particularly for Pavel's ones : polar_pi objsearch_pi iacfleet_pi ) What are the concerns about what kind of problems ? |
Beta Was this translation helpful? Give feedback.
-
For example https://github.com/nohal/dashboardsk_pi/blob/main/src/dashboardsk_pi.cpp#L162 will simply not work in your scenario as we will try to use a location not writable by the user running OpenCPN. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Pavel Not totally out of topic : |
Beta Was this translation helpful? Give feedback.
-
|
You are not supposed to touch that file manually, that's why it is in a hidden directory... But that is certainly completely off-topic here. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, we now have sort of a "dynamic catalog". That is, the effective catalog is made up from the downloaded XML file but also locally loaded tarballs. It should be perfectly possible to extend this to also add tarballs installed by a package manager. I have personally no plans right now to work with this, though. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Alec For the moment I continue to build my legacy packages to be sure that the paths are the same when we update from a version to an other Nevertheless it becomes to be difficult since in the tree of each plugin there' a link to a different commit version of opencpn-libs... |
Beta Was this translation helpful? Give feedback.
-
|
filochard... This is the current target we are using for plugin updates. |
Beta Was this translation helpful? Give feedback.
-
|
@bdbcat Re: Flatpak, I believe that weatherfax needs to use the flatpak version for audio rather than what we have built in. filochard has more information about this. If you want me to make a separate Issue for this, filochard or I can do that. Thanks. |
Beta Was this translation helpful? Give feedback.
-
It's IMHO not that important. These libs are statically linked and thus duplicated anyway, each plugin has it's own copy in runtime. And it would break the overall strategy that each plugin has it's own release and development cycle. |
Beta Was this translation helpful? Give feedback.
-
|
My notion is to get to the same commit of opencpn-libs for all plugins to promote stability, and remove another set of questions (like these) from plugin devs. Drop a dimension, if you will, from the plugin debug matrix. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Alec and bdbcat Since quite every plugin has now a dynamical link to a particular version of opencpn-libs to be built, I need to download all these different versions of opencpn-libs when I build the rpms It would be simpler if each plugin was rebuilt with a link to the last tagged version of opencpn-libs opencpn-libs-main-257338e |
Beta Was this translation helpful? Give feedback.
-
|
NOW BUT I hope this will help for the next updates of these plugins |
Beta Was this translation helpful? Give feedback.
-
|
If the plugin is using reasonably up to date opencpn-libs (= after the plugin_dc migration), you should be able to simply use the latest If you create the tarballs of the plugins from git, you can simply clone them with the submodule included (adding Is neither of these approaches usable in your workflow? |
Beta Was this translation helpful? Give feedback.
-
|
Hi |
Beta Was this translation helpful? Give feedback.
-
I wouldn't use the term "correctly" here. In the end, the overall paradigm is that each plugin is an independent community, and plugins' release cycle varies. And since the linkage to opencpn-libs is static each plugin carries it's own copy of the libraries it actually uses in runtime anyway and it's no problem if they are different The problem @filochard has is that he cannot really download or clone in the build phase, the distribution builders requires that all used sources are in place and available in a tarball before the build. So, the easy path here is a single tarball with opencpn-libs, but it breaks down when different plugins uses different versions of opencpn-libs. There are of course advantages w r t testing, overall simplicity and quality if most plugins uses the same commit. However, there is nothing in the upstream build process that requires this, and I'm far from sure that we will land there. Still, many (most?) plugins probably will. TL;DR; there is no "correct" version of opencpn-libs. |
Beta Was this translation helpful? Give feedback.
-
|
hm... the only "safe" route I see here would be to download the complete opencpn-libs git repo and use this as a source. That would make it possible for each plugin to checkout the version it uses. It's 140M so it's huge, put perhaps not unreasonable. |
Beta Was this translation helpful? Give feedback.
-
|
"TL;DR; there is no "correct" version of opencpn-libs." I generally agree. My goal is, as typical, to reduce the number of moving parts, so that we can concentrate on functionality rather than build tooling. |
Beta Was this translation helpful? Give feedback.
-
Yes, but this is not a guarantee from upstream that all plugins will use the same commit -- this is the important point here from @filochard's perspective. Besides that, not all plugins are using FE2. |
Beta Was this translation helpful? Give feedback.
-
|
I think now we are down to expressing personal preferences. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed opencpn-libs-main-257338e doesn't work to build some plugins from their source ! Look at /glu/CmakeLists.txt inside opencpn-libs-main-257338e Some plugins need /glu or /libglu being present to build (that's what I experimented when using opencpn-libs-main-257338e for them : the building aborted complaining of the absence of the glu headers) NB I didn't test yet these rpms : I'm still struggling with all this versions of opencpn-libs to build them... the first appearance of a link to opencpn-libs was a git of 9804fbe used in may 2023 by Now a link with opencpn-libs exists for these plugins and for lots of others that did not use it before I am afraid that there will appear a problem of consistency Maybe it's a stupid fear... but I experimented already problems when switching wxgtk from 3.0 to 3.1.5 and 3.2.0 |
Beta Was this translation helpful? Give feedback.
-
|
"257338e doesn't work to build some plugins from their source" |
Beta Was this translation helpful? Give feedback.
-
|
For example iacfleet_pi needed some changes to build against current opencpn-libs, see nohal/iacfleet_pi@cdcea04 |
Beta Was this translation helpful? Give feedback.
-
It's only you who have this problem. From the upstream perspective there is nothing which makes using the same commit "consistent". As @bdbcat said, we will probably use a common commit for many plugins for other reasons. But, again: there is no upstream guarantee that all plugins will use the same commit, and you need to adapt to this fact somehow.. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, but I still do not understand what is the problem here. Why don't you simply include opencpn-libs in the source tarball (created by git) you build. It is a git submodule and all it contains is built as part of the plugin and linked statically. Why do you need to create separate tarballs and care about what exact commit that submodule is at at all? |
Beta Was this translation helpful? Give feedback.
-
|
The problem as I understand it, is that some libs were relocated and moved to achieve more logical construct, and these changes required path changes in the plugins. While the organization of opencpn-libs settles there will be some of these kinds of problems that are being found with flatpak. |
Beta Was this translation helpful? Give feedback.
-
Hi David
celestial-navigation git clone f91c3f6
ais-radar 1.4.10.0 needs opencpn-libs-7ea37a1
|
Beta Was this translation helpful? Give feedback.
-
|
NB this is not a problem for me to create rpms with several different opencpn-libs versions for different plugins I only wonder if it will bring some problems in the future for the consistency of the plugins Since this first use of opencpn-libs, all the plugins now don't use the same version of opencpn-libs and are not built the same way : that doesn't appear for the maintainers, but that appeared clearly for me since I use separate tarballs for the plugins themselves and for the version of opencpn-libs they use My simple question is only : Will this create problems with those updated plugins ? I prefer seeming stupid with a silly question , than hiding a fear that I have ! |
Beta Was this translation helpful? Give feedback.
-
No. |
Beta Was this translation helpful? Give feedback.
-
|
And as I mentioned upthread, most of the existing plugins are in transition to opencpn-libs model, so the "official" repos (rgleason) are possibly broken. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the noise... I just ringed the bell and let you see it it's necessary to harmonize the version of opencpn-libs for all the plugins |
Beta Was this translation helpful? Give feedback.
-
|
PS (some sources inside opencpn-libs must sometimes be updated for security reason... and that would need a new tag for it, it would be simple to modify the link for each plugin) In a packaged linux system when a BuildRequire is updated, we rebuild all the packages depending on this BuildRequire to be sure they are corrected (particularly for security reasons) To comfort my point of view : we never use bundled sources to build packages The fact that opencpn-libs provides a lot of sources for all the plugins needing them allows to be sure that these sources are updated for all of them... and that is a very good point ! |
Beta Was this translation helpful? Give feedback.
-
|
You somehow miss the point here. Plugin development is not centralized, the basic model is that each plugin is a separate community. Thus, anything like "all plugins does whatever" is basically a bad idea. For that reason there are no tags in opencpn-libs, master is more or less a rolling release. I'm a packager myselt and is well aware how it works. That is one of the reasons we have avoided packaging plugins so far ;) |
Beta Was this translation helpful? Give feedback.
-
We might want to support plugins maintained by package managers. as discussed in #3216, one way or another.
Beta Was this translation helpful? Give feedback.
All reactions