On Fri, 21 Jul 2023 at 15:37, Thomas Goirand zigo@debian.org wrote:
NATS's preferred way of delivery is a single (!) binary offered by the upstream. I guess you could help considerably with minimum effort by repackaging it into a deb so that users going for apt hunting get the upstream NATS.
No way... :)
If I'm to do something, it wont be ugly bianry-only packaging. I was more thinking about doing a *real* packaging work, meaning packaging any missing Go dependency in Debian, and building from source. Otherwise, what value would this bring?
apt-get install support with automatic signature validation, version vetting with testing against your OpenStack stack. Just less work for you. In the end you can create two packages: one directly from upstream and one built yourself - and then compare the two. So many possibilities!
Then it would only boil down to finally packaging the Python library that works well with both OpenStack and NATS but we don't have it yet.
Considering the 400+ Python package I maintain for OpenStack in Debian, that'd be trivial 15 to 30 minutes work for me. :)
That's lovely to hear (read)!
Packaging a Go app the correct way, without breaking anything else in the whole Go stack in Debian is a way harder (ie: if something needs updating, then all reverse dependencies must be checked and possibly fixed...).
The point with Go is that it has no dynamic linking... and this is *on purpose*. What you would be doing is repeating the compilation to produce the single static binary and package it. The upstream does this well - no reason to repeat unless building for fancy architectures. This also helps with ensuring everyone is bug-bug compatible if they run the same version - no need to check anything else. :D