RE: Can't install Opera 51 on Ubuntu 14.04 LTS
Thanks @jimunderscorep for your reply
Statics builds can be proposed as rpm and deb packages too. Some devs C(++) in my team already did this plenty of times, so it's just totally possible, and it covers even more distros by doing so, meaning more users and revenues for your company (deb and rpm are just packaging methods, and do not imply that you need to do dynamic linked builds. dynamic linked builds are just distribution "politics", and very useful for "open source" packages, but non static builds for proprietary software is mainly the exact case of a wrong way to go).
Concerning your proprietary app, if you make a "static" build on a distro having the library (some change in the Makefile to make static builds), and since it's statically built you can remove some "Depends" from the "control" file in the deb source ("Depends" does not need all that is used for "Build-Depends"), than it could probably install as a deb package and work on your older distro (the deb package would just have some extra Megabites in size because of the static built-in libraries). For rpms, you have an src rpm and an rpm, you need a distro with the dependencies of the src rpm to build, but need less dependencies for the built rpm.
So to sum it up, it is totally possible to provide deb and rpm packages with static builds. Meaning you do not need to change an inch the distributing method. With C(++) apps It's no more than compiler options to pass during compile time. No more than that. Just a tiny little ting to change in the Makefile used to compile, and dependencies to remove in the "control" file of the deb package source (some "Depends" to remove).
All that is required is to build the package on a distro providing all the "Build-Depends", but then it installs on all distros having the "Depends" matching, and the less "Depends" you have in the "control" file, the more distro's it installs on.
Most of what is compiled statically can be removed from the "Depends" section.
Some packages well crafted can then run on a distro which can't compile it
NOTE: it's the wrong way to go for "open source", (and against debian politics for distribution packages) but this is not the case of Opera. It's that the distribution packagers' job to do backports and etc... if they want to provide a dynamic linked package. It's not the proprietary vendor's job, unless you want to open opera's source code and put it on github (You would be loved for this )
Currently you are using an open source package building strategy for a closed source app, this implies less distribution compatibilities.
The only thing that can be blocking is that some "extremely badly coded frameworks" may (I don't know your development framework) not allow this. If your framework allows this (if it's decently and intelligently coded), development would even be easier for your team because you would not need to do backports depending on distro libraries, and could even use more recent libraries without conflicting with the distro's own libraries, and the build would still be packaged in deb or rpm whatsoever, this would not change the way end users install.
I've already seen some deb packages with a Build-Depends library not provided by the distro, but statically built in the package, working properly.
I've even seen some proprietary rpms when I was working in Mandriva (Mandrake Linux) which where build on proprietary libraries we did not even provide or have at all. The libraries where simply statically linked by the vendor during the rpm build (so we where not even able to build the rpm ourselves). And believe me : it worked.
So I don't understand why you have a full open-source approach in package building for a closed source app unless you intend to surprise us and make your code open source in a while
I'm just trying to help propose that you have more users (and if your revenues depend on your users, well, you know what it implies).