How about providing appimages in add to .deb and .rpm packages? Appimage could be launched on any linux system. More info about appimages could be found on it's official website: http://appimage.org
Actually it is not true that a Vivaldi Appimage could be launched on any Linux system. Yes, AppImages have the possibility of including extra system libraries to handle dependencies but this is not the biggest issue in preventing Vivaldi from working anywhere. For the most part Vivaldi's dependencies are typically already satisfied on common distros once they are setup for desktop use. So any advantage there is minimal. In addition, to be truly universal, it is not just about library dependencies. All Chromium based browsers (Vivaldi included) use certain kernel features to allow our sandbox to work, e.g. user namespaces. User namespaces are not available in the default kernel of Arch and most Arch derivatives, nor in many distros with kernels older that 3.17 (unless the distro vendor has backported these features). Where user namespaces are not available in the kernel, we require our sandbox application to be SUID to root. This is not something that can be done within an AppImage. Thus a Vivaldi AppImage will not run correctly on Arch, most derivatives and older distros.
As for convenience, let's consider how a user would use a Vivaldi AppImage if one existed. After download there are two steps.
First the user makes it executable:
$ chmod +x vivaldi-1.4.589.29-x86_64.AppImage
Now the user can run it as follows:
$ ./vivaldi-1.4.589.29-x86_64.AppImage &
For comparison, how could a user on a non Debian-based distro use the deb file? After download there are two steps.
Extract Vivaldi from the .deb package:
$ ar p vivaldi-stable_1.4.589.29-1_amd64.deb data.tar.xz | tar xJ ./opt --strip 2
Now the user can run it as follows:
$ vivaldi/vivaldi &
So tell me again, what is the advantage of providing users with an .AppImage over a .deb?
Here is an example bug report from a user already struggling with running Chromium on Arch due to this very issue:
If you would like to try out an AppImage of Vivaldi, I have knocked up a quick package conversion script and placed it on GitHub here:
To use it you will need to have AppImageAssistant installed and must adjust the first variable in the script to point to it. You can get prebuilt binaries of AppImageAssistant here: https://github.com/probonopd/AppImageKit/releases
Once you have AppImageAssistant installed and the script configured correctly run it as follows:
$ ./appimage-vivaldi.sh vivaldi-stable_1.4.589.29-1_amd64.deb
At the end you should have a working Vivaldi AppImage.
Note: I am not bundling system libs within the Vivaldi AppImages this script creates for the reasons previously outlined.
I should also add that I do appreciate that AppImages have a couple of things going for them over manual deb (or rpm) extraction. Since AppImages for other projects exist and they have received some press of late, it is more likely that a user will know how to use one directly, compared with understanding that they can pull apart one of the packages we already provide. In addition, the fact that it is not a .deb or .rpm is also an advantage, since it encourages users to search online and investigate and hence they are more likely to work out how to use them.
Another thing that AppImages have going for them is that there is a method of doing delta updates. It is a little cumbersome right now as it requires AppImageUpdate and use of the command line but I see that the main developer has been doing some experiments to add the update mechanism to the file right click menu in Gnome and KDE, which is quite promising.
So in summary, I am not totally dismissing AppImages. We need to evaluate if it is worth while adding another package format (be that AppImage, Flatpak or Snaps) or continue to push for the distros to provide packages directly.
If you are interested in this topic you might also want to read:
P.S. Even though we only make .rpms and .debs directly we do test and will support Vivaldi on a much wider range of distros
This: "continue to push for the distros to provide packages directly" but with simpler licensing terms too clearly communicate exactly what is allowed, to reduce uncertainty and increase adoption of, a natively packaged, Vivaldi.