The advantages/disadvantages of classic tar packages
Back in the old days (long before Snap, Flatpak or AppImage), if a software producer wanted to offer a “universal Linux package” they would offer a tar package (sometimes referred to as a “tarball”). This would be a collection of files packaged up within a tar archive and suitably compressed. You would unpack this and install by running a handful of commands on the terminal. Usually you found a “README” text file within the package contents that would tell you exactly what to do. That might be manually copying a bunch of files into place, or running a standard tools (e.g. the classic “./configure && make && make install“) or perhaps a custom shell script, usually called something obvious like “install.sh”.
These methods certainly worked but had their issues:
- Installing requires a higher level of technical competence
- Often compilation steps would be needed, which means a complete development environment
- Addition dependencies (including compilation dependencies) would have to be installed
- Sometimes faults in the install steps could overwrite system files, that should not have been touched
- Often steps for a clean uninstall were incomplete, broken or completely missing leaving the user to just work it out themselves by reading the install script and trying to reverse the process manually
As you can see, it is not a surprise that most users these days do not want or ask for tarballs. 😉 However, when done well I would argue they are still pretty nice. It is always harder than a point and click for a novice user but many of the other difficulties can be somewhat diminished:
- By providing pre-complied binaries rather than source (so you can skip the build complications and potentially long compilation time)
- If the software requires nothing outside of that included in a typical desktop setup (no dependencies to worry about)
- A carefully composed install script
- A simple uninstall method
You then get the benefits of a universal package but without needing any back end like Snap or Flatpak. To be fair AppImage provides much of the same but often it is easier for the package maintainer to automate updates and desktop environment integration (and de-integration), or provide additional installation features, using just a simple script.
Before Flatpak and Snap, I made tarballs
Even as a tester working for Vivaldi, I appreciate a “universal package” as much as the next person. In part because I run a distribution that does not natively support our rpm/deb packages (I use Slackware) but also because I often have to test on other distributions. Many other distributions exist that do not support rpm or deb and not all of them have a suitable version of Vivaldi repackaged in their own software repository. Even if they have, I would still have to lookup the various install commands before I could test.
For these reasons I started making classic tarball packages some time back. Primarily for my own usage but also for the other testers. They exist for every stable, every snapshot and all internal builds that I share with our external, volunteer testing team (“The Sopranos”). They also support side-by-side installs. This means I can have 2, 3, … 10 … etc. Vivaldi installs on the same machine. Another feature is being able to run them self contained (so that the main settings are not touched and instead get stored in a directory alongside the launcher). I also have the option to easily disable updates.
These extra features are not something that the average user wants or needs, nor something that is easy to support with the standard package formats (that includes AppImage) but they are actually pretty handy features for testers when looking for bugs that appear with a certain update, since you can compare and contrast the behaviour of two distinct versions in real time, on the same machine.
These universal tarball packages are actually hosted on vivaldi.com, nonetheless they are not “official packages”, just my own test packages.
The problem with making them official is that:
- Official packages would require us to fully support them and thus spend resources testing for and fixing bugs
- They update themselves in a less secure manor than official packages and only in certain circumstances
Regarding the last point, my tarball packages can actually update themselves but only in certain configurations. Only for a single user install (since the script that performs the update does not handle process escalation). If you do side-by-side installs, only the “primary” one will update itself. The update check also only happens on browser startup.
Unsigned builds
However, perhaps more important than all of that is the lack of “signing”. The official packages have repositories that are digitally signed before their syncing to public servers. This means that if the public servers were ever compromised (unlikely… but… 🤷🏼) a nefarious hacker changing or replacing the builds there would break signing and thus the updates would not get installed. For these tar packages there is no signing and hence no signature check on updates. So a layer of defence is removed. But for internal testing purposes, that is “good enough”.
Understand what you are using
If you still think these packages might be useful, here is quick reminder/summary of things to consider:
- Issues relating to install and removal via these packages are not considered Vivaldi bugs (and may be ignored)
- Any problems on your system caused by these packages are your own responsibility
- The automatic update mechanism is limited and less secure than with supported packages, due to the lack of digital signatures
- As unsupported packages, they could be removed in the future
If you did want them nonetheless, the current stable for x64 (amd64, x86_64) as of 2024-12-18, can be found here:
or for the current snapshot:
If you wanted a newer version, just update the version number(s) in the above URLs. If you want a different architecture, just swap ‘x64’ with ‘arm’ or ‘arm64’.
Install options and handling updates
When installed via the bundled “./install” script (with no extra options, as a regular user), future autoupdates should be handled, albeit with some caveats. If you call the script with root/sudo or with an alternative install name “./install --name keyword” (where “keyword” is replaced with a word of your choice, allowing for additional side-by-side installs), no automatic updates will take place. You can also disable updates intentionally like so “./install --no-auto-update“. Finally, updates are only checked for on startup. If you rarely restart Vivaldi it could get out of date. In such cases the README file included suggests how to track updates yourself. It is also worth keeping in mind that security updates usually arrive on a roughly weekly basis, so if it has been over a week since your last upgrade, it might be time to update again. If you do fetch a new Vivaldi yourself, manually running the “./install” script bundled with the new version (using the same options as last time) will cause an upgrade.
Uninstall
To uninstall, a removal command is printed after the install step is complete (make a note of it for future reference) or alternatively if you still have an unpacked package “./install --uninstall” would also work.
Have fun… and remember, if these packages break anything, I accept no responsibility and neither does Vivaldi Technologies. 😉
Problems on Ubuntu (23.10+)
While I suspect it is unlikely you would want to install these packages on Ubuntu (where both deb and snap are an option), perhaps you can think of a reason why you might want to nonetheless. In such cases, you should be aware of an extra complication.
From Ubuntu 23.10, a sandboxing technology called “user namespaces” is disabled for most applications (there is effectively an allow list of Canonical defined applications†, where user namespaces can still be used). However the Chromium default (Layer 1) sandbox that Vivaldi prefers makes use of namespace support to function optimally. This is a problem if you run scripts such as “./install” or “./testrun” included with the tar packages. In such a case Vivaldi would fail to launch and from the terminal output you would likely see the error “The SUID sandbox helper binary was found, but is not configured correctly…” as Vivaldi attempts to load a fallback (SUID) sandbox. However that fallback cannot work without extended privileges, which the script (when run as a normal user) cannot configure.
Correcting the permissions on the fallback sandbox to get it working is not actually the ideal fix (despite the implications of that error message), as this fallback sandbox is less secure than the namespace sandbox, plus the permissions would reset every time Vivaldi was updated. The optimal work around therefore is to make an AppArmor exception for Vivaldi (when installed via the “./install” script), such that the better namespace sandbox will work. To do this, triple click the line below and paste it into your terminal, then press “Enter”. You will be asked to authenticate since it writes a file to “/etc/apparmor.d/vivaldi-tar” and restarts the apparmor service.
printf 'abi <abi/4.0>,\ninclude <tunables/global>\nprofile vivaldi-tar /**/vivaldi-bin flags=(unconfined) {userns,}\n' | sudo tee /etc/apparmor.d/vivaldi-tar >/dev/null && sudo service apparmor reload
† Vivaldi stable is actually in this “list”, albeit only with the install path used when installing directly from a .deb package [have a look at the file “/etc/apparmor.d/vivaldi-bin”, which is bundled with Ubuntu even before Vivaldi is installed]. Since the rule to allow user namespace access does not apply to Vivaldi when installed from the tar packages, due to the different install path, you need to setup an additional exception.
