Open Stack

On Fri, 21 Jul 2023 at 15:37, Thomas Goirand <zigo at 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