deltachat / deltachat-desktop

Email-based instant messaging for Desktop.
GNU General Public License v3.0
912 stars 167 forks source link

Make Arch/AUR package #426

Closed Jikstra closed 5 years ago

Jikstra commented 5 years ago

Investigated this a bit & this are the problems:

Other ideas:

I want to reuse the .deb package if possible because this allows us to be a bit sure about the used node modules/electron versions. The aur could also rebuilt everything, but because we don't really lock module versions, this can maybe lead to problems?

The-Compiler commented 5 years ago

My Arch system has /usr/lib/libsasl2.so, /usr/lib/libsasl2.so.3 and /usr/lib/libsasl2.so.3.0.0. Symlinking that to .so.2 would be a horrible idea (and probably wouldn't work), the whole point of the major version is that the two versions are incompatible.

Those are coming from libsasl 2.1.26 - is deltachat compatible with that at all?

ralphtheninja commented 5 years ago

Those are coming from libsasl 2.1.26 - is deltachat compatible with that at all?

Afaik, yes.

cc @flub

flub commented 5 years ago

yes, afaik etpan doesn't really care about the newer version of sasl or not. deltachat itself doens't care at all about sasl, it's only etpan's dependency.

i'm currently working on building a docker image which will build the deltachat-node stuff without dynamically linking to libsasl btw, and then this problem would go away (your first bullet point in other ideas essentially).

flub commented 5 years ago

"Normally" you should be good with any /usr/lib/libsasl2.so* version. The normal layout is to have the actual lib libsasl2.so.2.0.25 and have both libsasl2.so.2 and libsasl2.so be symlinks to the actual lib.

Jikstra commented 5 years ago

@The-Compiler thanks for joining the discussion :)

@flub "normally" but not for arch, it's using libsasl2.so.3 even if the version number is 2.1.26-13. Maybe it's too new? However, the all included deltachat-core will probably solve this problem :)

Docker is also a good idea, we could just use docker to build the arch packages. electron-builder supports that.

flub commented 5 years ago

for e.g. libsasl2.so.3.0.1 (and all it's symlinks): soname = libsasl2.so.3 The purpose of the libsasl2.so symlink is so that at build time this one is used (-sasl2), but at runtime the soname is used.

So you have a newer version of libsasl than the node extension was linked against. sasl decided that a part of their ABI is not backwards compatible since libsasl bumped the soversion. You need to either install libsasl2.so.2 or re-build the node extension against your libsasl.

ralphtheninja commented 5 years ago

i'm currently working on building a docker image which will build the deltachat-node stuff without dynamically linking to libsasl btw, and then this problem would go away (your first bullet point in other ideas essentially).

:heart:

It would be nice if you could base it on this Dockerimage https://github.com/deltachat/docker-images/blob/master/debian-stretch-node-11/Dockerfile (or tweak the existing).

Jikstra commented 5 years ago

@The-Compiler can you give https://github.com/Jikstra/deltachat-desktop-git-aur a try?

The-Compiler commented 5 years ago

Nitpicks:

Other than that, it looks fine, and installs/works. Takes 105 MB (not including dependencies such as Electron itself), but I guess that's to be expected.

Jikstra commented 5 years ago

@The-Compiler thanks a lot for your review, applied your nitpicks.

Jikstra commented 5 years ago

It's done. https://aur.archlinux.org/packages/deltachat-desktop-git