[Dev] 3rd party so library installation feature
jussi.laako at linux.intel.com
Tue Oct 22 08:57:58 GMT 2013
On 21.10.2013 15:11, Łukasz Stelmach wrote:
> I'd rather not use proprietary software.
Not supporting proprietary software properly will just keep Linux as
obscure system for most end users.
> 1. In some sort of packages rathare than with self-extracting
> archives/installers. Depending on whether it is a "user software"
> (e.g. Photoshop, AutoCAD) or "system software" (e.g. database servers)
> one of two packaging systems should be used: user packages or system
> packages. At the moment we've got only the latter. Even if the file
> formats allow the software that supports them do not provide support for
> "user packages". Even if rpm(8) itself can be forced to work like this
> GUI applications are not tailored for such use-case.
Because of dependencies for different runtimes one shouldn't try to draw
too much difference between the two. One bad way common on Windows is
for applications to install things like Visual Studio runtimes to the
system directories. Another bad way common on OS X is to include all
shared libraries in the application bundle which is from resource
consumption point of view equal to shipping applications statically linked.
> a) building for a particlular version of a prticular distribuiton with a
> tool like OBS, which works for "system software".
Centralized builds for proprietary software is never going to work.
Instead you can build packages in normal way for the particular distro
and then let end-user install it. Just like Opera does. So far this
works best on Ubuntu. LTS has decently infrequent release rate, although
most of the time software built on LTS will also run fine on
intermediate releases before next LTS.
> b) establishing a standard sets of ABIs that a "user software" can rely
> on. Standard ABIs could be supported by different distributions.
This is largely true already, but the problem is more on the software
management side, installing/un-installing in a nice way.
> 3. There should be a platform for running "user software" in a confined
You practically cannot make the distinction or you severely limit the
platform. User needs to be able to hook items into the system, like
installing new codecs or system components. OS needs to provide enough
extension points too.
> What I've seen under GNU/Linux are greate packaging systems that
> make system maintanance nice and easy task, although building packages
> for every version of every distribution out there is a bit of a headache
> for an ISV.
I think that is still one of the least troubles. Packaging system also
helps avoiding conflicts (although in the past Debian managed to bake
conflicting packages into their distro, haven't noticed this anymore on
More information about the Dev