Add frozen metadata mechanisms

[leamas]

Maintaining frozen metadata is a major pain for plugin devs. The basic problem is to track what is frozen or not.

This PR adds a new. source directory frozen-metadata. It is aimed for plugins for old distros which we don't build anymore but still keeps around. The basic change is to the ocpn-metadata scripts whichnow is able to use sources from both directories.

For a plugin dev the act of freezing a plugin is

1. In the plugins local copy, move the last build of plugin to frozen-metadata
2. Make sure that no new builds are done for given plugin and OS version

The PR is ready, but we might need to reflect on if this is the right solution

[bdbcat]

There is a bigger issue that we need to discuss now, IMHO.
While archiving the metadata is good, we have no guarantee that the embedded tarball link (points to Cloudsmith...) will be available indefinitely. Relates to retention policy of Cloudsmith repos.

[rgleason]

This is a great start. Thank you Alex.

Perhaps a script to upload metadata and tarball to an opencpn.org directory and to change the metadata path accordingly?

How to manage access to this action? Maybe specific users authenticated somehow?

[leamas]

My name is Leamas.

Alec Leamas

The long term storage is indeed an issue. In situations we don't trust Cloudsmith to keep the storage available, the only solution is probably that we pay for it. Going this path means usinhg the repo.opencpn.org VM which is trivial. The storage should not be that much, and as long usage of old versions is limited the IO should be reasonable as well.

But then again I think we should focus on a better way to handle frozen metadata here and now. This is about making the final Bullseye and upcoming Trixie builds easier to handle for plugin maintainers.

So basic question is IMHO if the proposed path here is OK.

[leamas]

hm... thinking about it, I can see a workflow for freezing plugins:

1. Plugin devs moves the metadata to frozen metadata
2. Plugin devs stops creating new versions for frozen plugin/OS/version
3. Plugin dev makes, as usual, a PR
4. From the point the PR is accepted the plugins project is responsible for managing the frozen plugins.
5. Plugins project (Dave, perhaps me) moves frozen plugin tarballs to somewhere and updates the metadata.
6. Plugins project maintains it's own retention policy; we can't keep plugins around forever.

But then again, this is if Cloudsmith long term storage actually is a problem...

[rgleason]

Sorry Alec, sometimes I forget. Regarding retention policies in Cloudsmith, prod is set for long term, but we should not rely on it not changing for opensource, I think. There will probably be some limits eventually.

PS: I think your solution for moving frozen PI is good. I like the simplicity.

[rgleason]

Sorry Alec, sometimes I forget. Regarding retention policies in Cloudsmith, prod is set for long term, but we should not rely on it not changing for opensource, I think. There will probably be some limits eventually.

For users of older OS, we will need some brief notes in wiki, for how to access older plugins via the online portal, selecting for OS etc. Correct?