Enforce our system requirements

[fmarier]

https://support.brave.com/hc/en-us/articles/360021357112-What-are-the-system-requirements-to-install-Brave

We could simply do like Tailscale and return OK for supported distros: https://dl.brave.com/release/ubuntu/bionic/installer-supported

Since we don't have different requirements for different channels, /beta/ and /nightly/ could be symlinks to /release/ for nowl

[fmarier]

These files could be hosted in the present git repository.

[wknapik]

With the distro and architecture checks in place, is it necessary to have more?

[fmarier]

We should at least check for the min versions for each distro because Brave won't work on old Debian/Ubuntu for example (Chromium limitation).

[wknapik]

Can we express the requirements in terms of something other than distro versions? We'd have to cover a lot of distros and it would be easy to fail where we shouldn't. Plus I'd rather minimize the maintenance effort. If we could boil it down to a check for some local package versions, or something, that would be nice.

[fmarier]

In the interest of getting the MVP of that script out, let's stick to the way that Tailscale does things for the time being.

If we get dl.brave.com/release/... to (essentially) proxy the /release/ directory in the GitHub repo, then we can easily mark new distro versions as supported with a simple PR (adding a file). No need to re-deploy the script or anything like that. For the time being, we can rely on user reports (or PRs once this repo is public) to keep up with new Ubuntu/Debian/Fedora releases, though we could also monitor the 404s and send them to a Slack channel (https://github.com/brave-experiments/install.sh/issues/17).

We can revisit when/if this becomes annoying to maintain. It's easy to change later because we won't support old versions of this installer script and so all that's needed to move to another way of checking the system requirements is to update install.sh.

[wknapik]

There's two main issues with the approach Tailscale took - it has never ending maintenance built into it and it may block installation when it would otherwise succeed.

The way the script currently determines which package manager to use has similar issues.

>200 lines are devoted to figuring out which distro name/version the script is running on, which package manager to use and whether the distro is supported, all based on specific distro names/versions. Why not just check which package manager is available and then use it? There's only 5 - apt, dnf, pacman, yum and zypper.

If I create a new distro today, which uses any of the above package managers, the script should work on it. If we follow the Tailscale approach, the script will fail and we'll have to modify both the script and the check endpoints and create a new release to make it work.

IMO it's better to occasionally install the browser when it's not supported, then to fail installation when it is supported. And we can still figure out a check that is not based on distro names/versions (brave thread, chromium thread).

And not having to maintain a list of distros and versions forever would be very much desirable.

And we could shrink the script at least to half its current size.

[wknapik]

I think this could be our compatibility test

[ "$(printf "%s\n%s" "$(ldd --version 2>/dev/null|head -n1|grep -oE "[0-9]+\.[0-9]+$")" 2.26|sort -V|head -n 1)" = 2.26 ]

and then just install based on what package manager is available, skip all the distro checks.

This would get rid of most of the code and all of the remote infra. Maintenance would consist of bumping the version in one line in the script once in a (long) while.

Why this line exactly? It checks whether glibc is at least 2.26. That's the oldest version among the officially supported distro versions (Mint 19). This also lines up with

% objdump -T /opt/brave-bin/brave|grep -o 'GLIBC[^)]*'|sort -uV|tail -n1
GLIBC_2.25
%

Our official requirements are Ubuntu 18.04+, Mint 19+, Debian 10+, openSUSE 15+, Fedora 28+ and Rocky 9+.

Chromium's are Ubuntu 18.04+, Debian 10+, openSUSE 15.2+, or Fedora Linux 32+.

Here's compatibility according to the one-line test

% for img in alpine voidlinux/voidlinux-musl ubuntu:16.04 ubuntu:18.04 debian:9 debian:10 linuxmintd/mint18-amd64 linuxmintd/mint19-amd64 fedora:26 fedora:27 opensuse/leap:42.3 opensuse/leap:15 opensuse/tumbleweed rockylinux:8-minimal; do echo -n "$img: "; docker run --rm -it "$img" sh -c '[ "$(printf "%s\n%s" "$(ldd --version 2>/dev/null|head -n1|grep -oE "[0-9]+\.[0-9]+$")" 2.26|sort -V|head -n 1)" = 2.26 ] && echo supported || echo not supported'; done
alpine: not supported
voidlinux/voidlinux-musl: not supported
ubuntu:16.04: not supported
ubuntu:18.04: supported
debian:9: not supported
debian:10: supported
linuxmintd/mint18-amd64: not supported
linuxmintd/mint19-amd64: supported
fedora:26: not supported
fedora:27: supported
opensuse/leap:42.3: not supported
opensuse/leap:15: supported
opensuse/tumbleweed: supported
rockylinux:8-minimal: supported
%

[fmarier]

Assuming glibc is the only thing we have to worry about in terms of compatibility, that seems like a good solution. We can always go back to a Tailscale-style check if we run into problems later (i.e. trying to install on a distro that cannot support Brave despite having the right glibc and package manager).

We should ideally retain the distinction that the upstream script makes between "known to be incompatible" (i.e. for us that would be glibc < 2.26) and "unknown" (i.e. we can't find a supported package manager). (For the "unknown" case, the Tailscale installer invites the user to email the content of some of the distro metadata to them.)

[wknapik]

Assuming glibc is the only thing we have to worry about in terms of compatibility, that seems like a good solution.

It might not be the only thing, but in practice, glibc bumps come with bumps to everything else and Chromium will likely keep bumping distro support in major version/LTS increments, so I think this might just be good enough.

And if we need to do additional checks, we can add them later, on top of the glibc one.

We should ideally retain the distinction that the upstream script makes between "known to be incompatible"

Sure.

(For the "unknown" case, the Tailscale installer invites the user to email the content of some of the distro metadata to them.)

In this case we wouldn't create a package for a new package manager anyway, so maybe we shouldn't ask for a bug report?

[wknapik]

Here's a preview that drops >300 lines (423 -> 116)

[fmarier]

In this case we wouldn't create a package for a new package manager anyway, so maybe we shouldn't ask for a bug report?

I think it's good to have a record of what distros users would like us to support. We don't have to commit to adding the support ourselves (others may be inspired to do a third-party package).

[wknapik]

I think it's good to have a record of what distros users would like us to support.

It sure is, but I'd rather not ask a user to make an effort if they're not going to see any payoff.

We don't have to commit to adding the support ourselves (others may be inspired to do a third-party package).

An issue in our bugtracker probably wouldn't inspire that, unless you were thinking of asking for a community post, or something? Or maybe a post somewhere distro-specific?

[wknapik]

@fmarier https://github.com/brave-experiments/install.sh/pull/31 is ready for review. We can change the message for the missing package manager, please comment with your suggestions.

[fmarier]

I think an issue (i.e. feature request) in our bug tracker is ideal. Sure, it's no guarantee that we'll ever have time for it, but at least it sends a signal that a non-zero number of people would like Brave on that platform. It's also something that people can thumb-up.