Federation is a wonderful thing to have, but not at the expense of making everything convoluted.
I'unno, maybe it's just the Arch user in me speaking. But I don't think you really need a distribution to do one thing well when you can just fine-tune the one and have a better overall experience for your troubles.
@lanodan I don't agree, and most people want something easy to update and install, and I'd prefer not to deal with outdated Elixir versions. I want Pleroma instances to be easy to setup, and that means having easy to install releases IMO. Most people still run Debian 10, not everyone's going to use Gentoo or anything else... (and Raspbian, too)
@lanodan which is why full-static linking would be preferable, so we could have one-binary-runs-everywhere (the only thing that stays mostly consistent are the Linux syscalls, after all)
@helene I meant outside of packages. Maybe a deb repository could be done, or just giving .deb packages instead of a basic tarball.
I've tried pushing for a proper recipe in the AUR, our OTP builds being for Alpine for the musl flavor and Debian and compatible for the glibc flavor. We *can't* support distros with other release schedules like Arch, Void, Fedora (or even Ubuntu) via a single OTP build.
@lanodan so we could just not use glibc then? musl is preferable anyway and what's the problem with statically linking OpenSSL? if need really be, I'd remove that dependency from OTP in some form lol, I don't particularly like OpenSSL anyway
I still don't understand what the issue of having a 100% static build, it would work no matter the distro for libnss there can be workarounds
@helene full-static *cannot* work with glibc, specially when stuff linked to nsswitch.conf like hostname resolution is used. And a static-link with OpenSSL inside is a recipe for horror.
For musl well lol, there is basically just Alpine and Void in terms of distributions with binary packages (let's not try to support gentoo-musl with binaries).
@helene Static-linking OpenSSL (among other libs pulled by us and erlang) means that any security updates needs to be addressed. And OpenSSL has a security issue on basically a monthly basis.
@helene Yeah, meaning shipping a rebuild *just* for OTP users.
And that's just OpenSSL, full-static should mean watching all the vendored dependencies for similar kind of issues, effectively becoming a distro. Feel free to try that but that's absolutely not a thing I would maintain.
@lanodan@helene Problem with dynamic linking is that every distro has different ideas on where libraries have to be, /lib, /usr/lib, /lib64, /usr/x86_64-linux-gnu/lib, /gnu/store/hudfsiuhfw4uhdfiushf4wf0h-openssl-1.4.3a/lib. Now you'll either have fun with RPATH, patchelf, vendoring the libraries (arguably worse than statically linking), or your official binary will support only one small family of distros.. or you could link statically.
In any case, if pleroma decides to go the static linking path, I just have the request of "pls don't force static linking on every person who wants to build it".
@helene OpenSSL does solib bumps on ABI breaks (ie. libcrypto.so.1.0 → libcrypto.so.1.1), so with a package manager it's goes fine without having to go with static-linking.
@ukko@helene Dynamic linking usually doesn't have that problem at all, see ld.so.conf It just does for the special snowflakes that are GuixSD and NixOS, it's their problem, they fix it, and in the case of NixOS they more or less did via packaging.
> pls don't force static linking on every person who wants to build it
Shouldn't even need to be said, static-linking on the current state of package builders is quite shooting yourself in the foot.
@lanodan@helene couldn't it be as simple as just having a nightly build that includes pulling newest versions for all deps? I don't think pleroma has any sort of automatic update checking anyways so doesn't even matter if there's some timestamp making it non-reproducible
The build server can just spin up an unstable Debian container for the nightly build job. (Let's ignore getting a statically linked OTP and everything for now.)
The end-user would run the normal pleroma_ctl update.
And if you're building it from source you'd probably not care about statically linking everything and instead would just build it to dynamically link to whatever your system has anyways.