We have the following beta builds for Linux:

qt-linux-opensource-5.0.0-beta1-x86-ubuntu1110-offline.run
qt-linux-opensource-5.0.0-beta1-x86-ubuntu1204-offline.run
qt-linux-opensource-5.0.0-beta1-x86_64-ubuntu1110-offline.run
qt-linux-opensource-5.0.0-beta1-x86_64-ubuntu1204-offline.run

A .run file is quite a non-standard way of installing packages on any Linux distro, let alone Ubuntu. Why do we put ubuntu in the name if it's going to be an improper Ubuntu package? Why not make .deb packages ourselves? Is there some reason we leave it up to Canonical to do that? (Just to save the trouble, or because they like it that way too?)

If there is to be a binary installer I think it should be more portable. I tried installing one of them on Arch Linux, and the only problem as far as I can tell is

libicui18n.so.48 => not found
libicuuc.so.48 => not found

This is because I have ICU version 49. Of course, this is probably the fault of libicu for not caring about maintaining compatibility between versions, but I have also verified that it's still possible to build Qt without that dependency. I configured it like this:

MAKEFLAGS=-j20 ./configure -developer-build -opensource -no-glib -no-iconv -no-accessibility -no-nis -no-fontconfig -no-pch -no-dbus -no-libudev -xcb

and got a working version in which the assistant binary, according to ldd, depends (directly and indirectly) on only 28 libs instead of 65:

linux-vdso.so.1 (0x00007fffa0fff000)
libQtPrintSupport.so.5 => /home/rutledge/dev/qtmt-latest/qtbase/lib/libQtPrintSupport.so.5 (0x00007f255010f000)
libQtHelp.so.5 => /home/rutledge/dev/qtmt-latest/qtbase/lib/libQtHelp.so.5 (0x00007f254fe77000)
libQtWidgets.so.5 => /home/rutledge/dev/qtmt-latest/qtbase/lib/libQtWidgets.so.5 (0x00007f254f4af000)
libQtSql.so.5 => /home/rutledge/dev/qtmt-latest/qtbase/lib/libQtSql.so.5 (0x00007f254f265000)
libQtNetwork.so.5 => /home/rutledge/dev/qtmt-latest/qtbase/lib/libQtNetwork.so.5 (0x00007f254eed4000)
libQtGui.so.5 => /home/rutledge/dev/qtmt-latest/qtbase/lib/libQtGui.so.5 (0x00007f254e7b8000)
libQtCore.so.5 => /home/rutledge/dev/qtmt-latest/qtbase/lib/libQtCore.so.5 (0x00007f254e094000)
libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f254dd79000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f254db5d000)
libstdc+.so.6 => /usr/lib/libstdc+.so.6 (0x00007f254d859000)
libm.so.6 => /lib/libm.so.6 (0x00007f254d55f000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f254d34a000)
libc.so.6 => /lib/libc.so.6 (0x00007f254cfa6000)
libQtCLucene.so.5 => /home/rutledge/dev/qtmt-latest/qtbase/lib/libQtCLucene.so.5 (0x00007f254cc0c000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f254c9f9000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f254c6c0000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f254c4aa000)
libpng15.so.15 => /usr/lib/libpng15.so.15 (0x00007f254c27d000)
libpcre16.so.0 => /usr/lib/libpcre16.so.0 (0x00007f254c02a000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f254be26000)
librt.so.1 => /lib/librt.so.1 (0x00007f254bc1e000)
/lib/ld-linux-x86-64.so.2 (0x00007f2550379000)
libnvidia-tls.so.302.17 => /usr/lib/libnvidia-tls.so.302.17 (0x00007f254ba1b000)
libnvidia-glcore.so.302.17 => /usr/lib/libnvidia-glcore.so.302.17 (0x00007f254966a000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f254944c000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f2549247000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f2549041000)

Except for perhaps libpng, which has also had a major version change recently, I suspect this build is quite portable, and would work well on oddball x86 distros which don't have Qt packages. As it is, we are basically leaving everyone to compile for themselves, while I would not recommend anybody to actually use the so-called ubuntu package, because after you install it, apt does not know about it and therefore it will not be kept up-to-date.

The binary portable installer should install in /opt/qt or /opt/qt5 by default, too. (Even if it has to transparently use sudo or su to get permission.) Maybe a home-directory installation is appropriate for the beta, because it's intended to be deleted cleanly pretty soon after, but hopefully not for the release. It could also have a option to install libs in /usr/local/lib, binaries in /usr/local/bin and so on, as an alternative for people who don't like putting /opt/stuff in their paths.