Open Stack

On 7/21/23 11:59, Radosław Piliszek wrote:
> On Fri, 21 Jul 2023 at 09:03, Thomas Goirand <zigo at debian.org> wrote:
>>> Unfortunately I didn’t get any feedback from the company maintaining the nats.py library
>>> on supported developer time implemeting the sync client feature, I assume (my view) that
>>> they didn’t like that we cannot guarantee that NATS would become a core component (or used, or the primary bus)
>>> in the ecosystem (since we don’t, and don’t want to for that matter, force a backend/driver on operators).
>>>
>>> Any help is of course appreciated, right now this is not a top priority and I don’t spend any full-time
>>> effort into it.
>>
>> Would it help if I was packaging NATS in Debian (and therefore, as a
>> consequence, in Ubuntu)? By reading the go.mod, it feels like it has a
>> reasonable amount of dependencies (though I didn't check for the
>> indirect ones), so it feels like doable...
> 
> 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?

> 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. :) 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...).

Cheers,

Thomas Goirand (zigo)