[Dev] 3rd party so library installation feature

Jussi Laako 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
> environment.

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 mailing list