Packaging?

[DC7IA]

Is packaging planned?

Would love to see this for example in the Debian repos. :)

[boxdot]

I have some experience with packaging deb, but only in private repositories. I will take a look what is needed to land in the official repo.

@gferon You have experience with Fedora, right?

[DC7IA]

Debian recommends to not use Repos that are not part of Debian: https://wiki.debian.org/DontBreakDebian

However, if you'd let the binary update itself, that'd also work. :D

With youtube-dl, simply typing youtube-dl --update updates it. Something like that would also be great.

But getting gurk into the official repos of a distribution opens it to a much broader audience and should be preferred.

[gferon]

@gferon You have experience with Fedora, right?

I do, it should be relatively straightforward.

Two things I'm not too sure of:

• I seem to remember that Debian packages crate separately, and dynamically link them together, which makes the job much harder given the dependency tree of gurk
• Are we in a stage where we want to publish the binary in some central place and advertise it as fully functional?

[boxdot]

Are we in a stage where we want to publish the binary in some central place and advertise it as fully functional?

I think, not yet. What is on the list, is to encrypt the messages database and store in a sled db, instead of a plain json file. This is definitely the most important non-user facing feature. Another feature, more important for users, is to implement attachments preview view links.

[Tachi107]

Hi! I'm a Debian Maintainer, and I'd love to see gurk in the main Debian repos too :D

Unfortunately I have little familiarity with Rust's ecosystem (I have no issues with the language itself though), and I've never packaged a Rust program for Debian (yet).

According to the Readme gurk cannot be published to crates.io because of its dependencies, and @gferon's comment isn't reassuring either :/

Could you please expand a bit on gurk's atypical dependency tree?

[gferon]

Thanks for your interest in packaging this. We have two main problems with packaging at the moment:

• We depend on libsignal, which is the official library from the Signal organization, and we started a discussion where they explained that it's a good idea but they would like to drive this effort and decide how to do it. In the Rust ecosystem, crates are usually first distributed on crates.io (which libsignal is not)
• The underlying projects powering Gurk need rather frequent adjustment (every few weeks at best) to catch up with changes in the Signal service, which would make it rather incompatible with the release cycle of a stable distribution like Debian

[boxdot]

As @gferon pointer it out, the official client library by the Signal organization is not published on crates.io, and therefore it is not possible to publish this crate on crates.io too, because we depend on Signal's library transitively (https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-dependencies-from-git-repositories).

The underlying projects powering Gurk need rather frequent adjustment (every few weeks at best) to catch up with changes in the Signal service, which would make it rather incompatible with the release cycle of a stable distribution like Debian

This actually might be ok, as long as we keep backwards compatibility in gurk. And usually we do.

[gferon]

What I meant by that is the applications just stop working because of changes in the servers.

[boxdot]

Got it. You mean the stability of the features. From my personal experience, the application is quite stable for me. I am using it for more than 2 years almost every day. The most unstable feature was so far the groups. But it seems that signal is introducing quite some changes there. To mention one is the switch from phone numbers to uuids.

[gferon]

Another example is registration and linking, and more recently additional http statuses for error handling, that had to be repeatedly fixed. New features also became required, like sealed sender messages.