Switch to upstream ostree go bindings

[evelikov]

While hacking on a CI lint stage for debos, I noticed that we're using a fork of https://github.com/ostreedev/ostree-go namely - github.com/sjoerdsimons/ostree-go

Seemingly there are two upstream MRs needed in order to converge:

• Sysroot support ostreedev/ostree-go#10
• Switch to more modern GObject strategy ostreedev/ostree-go#34

Create this a task here so there is some clarity and cross-references. @sjoerdsimons @eds-collabora
feel free to provide background information and details as you see fit.

[obbardc]

I think there are more upstream PRs needed to be created than the two you have linked.

Some baby-steps going forward:

1. move the fork to the go-debos namespace & switch debos to use the go-debos fork
2. rebase the fork ontop of https://github.com/ostreedev/ostree-go & drop merged commits
3. find out what remains to be pushed upstream, split into branches and create PRs upstream
4. switch debos to upstream repository and remove go-debos fork

How does that sound for a plan of attack?

[eds-collabora]

I believe that PR 34 is a subset of a more recent version of PR 10. I got one trivial PR merged when I tried, but got absolutely no traction for this. No questions, nothing. I had more PRs planned/branched that then built on this to bring the codebases into alignment, but I couldn't get off the starting blocks.

[sjoerdsimons]

ostree-go isn't very active generally and there are a bunch of issues around the go garbage collector and ostree works.. I've been wondering if it doesn't make more sense to do a small C/Rust wrapper for libostree directly in go-debos that provides a minimal/trivial API to just address the few operations go-debos needs, rather then fighting the golang binding

[evelikov]

While I do agree that upstream being slow/inactive is a hurdle, it seems that adding a new wrapper will add more technical debt/burden to go-debos. I'm a little concerted that using different language may raise the bar for contributions and/or adoption.

That said, the decision is above my noobie contributor status to the project, so take my input with pinch of salt.