Plugin building/installation for source based Linux distros.

[nxmyoz]

Hello there :-)

a Gentoo Linux user here:

I'm currently maintaining (to some extent) OpenCPN packages in my private portage overlay.

Recently, I wanted to update all ebuilds of plugins for OpenCPN and noiced, that the cmake of the oesenc plugin no longer allows me to build and install the oesenc plugin directly, that is without flatpack or OpenCPN tarballed plugin infrastructure...

That is a bit inconvenient, because it takes away the freedom of packaging under source based linux distros, at least I think.

So I wanted to know if the decision to offer the packaging as of now is final or whether there is a chance to revert to the old state, where it was possible to package a plugin the traditional way?

Also I wanted to know the background for such a design-decision, why it was decided to remove that "classical" way of packaing?

Thanks in advance for a reply ;)

[bdbcat]

To answer your last question first: The primary motivation is to increase uptake on plugins by moving the installation process to user-space. Secondary motivation is to streamline plugin maintenance. We support a large number of platforms, each with various quirks. When multiplied by the plugin count, you can see that this is a large matrix. Our goal is to fully populate that matrix. Creating a uniform CI-driven plugin build system allows rapid bug fixing and near-immediate deployment, for all platforms simultaneously.

I suggest that you leverage the existing plugin infrastructure. Build tarballs and metadata, upload to whatever server you like. You should then, probably, be able to add your plugins to the OCPN plugin plugin management system. Of course, if you are only interested in a few, or one, plugins, then you could fork the plugin repo, make the small changes required for traditional packaging, and proceed that way. In any case, you should consider the current plugin packaging and management system as fixed and final. Dave

[nxmyoz]

Thanks for the insights. Sorry to hear, that there is no way back.

As for using the existing plugin infrastructure: creating the tarballs assumes building using those dependencies, found on the system. Especially when using source based distros, the pace at which dependencies may change (versioning & co.) differs in comparison to mainstream binary distros. Having the ability to recompile without further complications is an advantage.

That being said, OpenCPN plugins tend to be rather nasty (no offence - fiddling with the build of 20+ plugins I can't say it's an enjoyable task) on the cmake part and require a lot of tweaking, to get building on Linux distros aside from Windows/mainstream Linux distros. So simply put, using the OpenCPN plugin infrastructure as it stands now makes it easier for Windows, Flatpack and maybe mainstream binary distros to distribute the plugins, but will require either even more magic and hence work and time in packaging or a complete shift to Flatpack (I think Arch Linux is removing the packages altogether because of this), which by itself creates a redundancy in packaging. Seems rather to be another attempt at reinventing a wheel...

As for the CI: I do not see a contradiction in having the option to be able to build locally as before, imho.

So, "not great, not terrible" but not nice either :(

Thanks for your effort with oesenc, though :-)