Generate .deb file in CI

[julianoes]

This is an attempt to publish a .deb file for Debian/Ubuntu containing the generated MAVLink headers.

This also adds support for pkgconfig by the cmake build/install.

The release version is taken from github tags in the form of vX.Y.Z.
We just use the git hash instead for now.

The idea would be to use this .deb file to install MAVLink as required by MAVSDK.

FYI @hamishwillee and @auturgy.

[julianoes]

@JonasVautherin now I wonder where we would put this .deb file because we're not actually making releases.

[hamishwillee]

@JonasVautherin now I wonder where we would put this .deb file because we're not actually making releases.

We're backwards compatible, so we could put it in-tree as latest build and overwrite each time we generate the library. Or in its own repo, but seems annoying.

Or we bite the bullet and agree a release process. That requires agreement and time. I don't think insurmountable - we've never committed enough time to make a solid proposal.

[julianoes]

I wouldn't put binaries in source. Versioning sounds reasonable, doesn't it.

[hamishwillee]

So this is closed, does that mean I don't have to think about a response to "I wouldn't put binaries in source. Versioning sounds reasonable, doesn't it."?

[julianoes]

Closed by accident, pretty sure.

[julianoes]

Oh, I forgot about the aspect of needing a github release to actually put the .deb file, and that's clearly not happening any time soon. I'm giving up on this, it needs a broader push regarding MAVLink versioning.

[hamishwillee]

Well, as discussed, we could have a meaningless release - i.e. weekly tag say. As long as it is clear this is just for the purpose of meeting deb file requirements and doesn't map to particular milestones or deliverables then why not. I'd trigger it automatically on mavlink updates of ArduPilot/Pymavlink submodule. If we were being ambitious, we could also sync those to the git hash used in Pymavlink releases.

[julianoes]

Right. I'll think more about it.

[JonasVautherin]

It could also be triggered e.g. every two weeks, and the tag would just be a date. Some kind of "bi-weekly build".

[hamishwillee]

I think we should do that - it's just a "tag release", not an "official release". That presumably sorts the requirement of the .deb file?

[hamishwillee]

FYI @JonasVautherin (@julianoes) We discussed in the dev call. MAVLink is happy for tag releases to be created in a workflow - monthly cycle preferred, but 2 week if you need it. It will just be a date release, with no tracking of changes or whatever. We're not planning on linking it to anything other than a date (such as pymavlink versions, or containing particular messages)