[Dev] 3rd party so library installation feature

Łukasz Stelmach l.stelmach at samsung.com
Tue Oct 15 15:27:21 GMT 2013


It was <2013-10-15 wto 14:10>, when 함동읍 wrote:

> I want to discuss "3rd party so library installation feature.

tl;dr

Technically it is possible, however, in introduces a dependency hell.

> Requirement
>
> 1. To provide a way to download a necessary shared library from
> authorized/dedicated site
>
> 2. If users want to use application B which uses a shared library,
> they download that library from the site by themselves.
>
> 3. When another application C requires the same library later, users
> can use it without additional download.

Technically, package manager that resolves dependencies is not a
problem. Basically what you describe is a package management system,
like RPM.  However, all my experience with such systems on different
platforms (GNU/Linux, Windows) tells me that it is next to impossible to
create a system (with the widest meaning of the word "system" thant
incluedes all the 3rd party developers and distribution channels) that:

a) supports package dependencies,

AND

b) allows packages to be supplied by different vendors (especially if a
one external vendor depends on another's packages).

> 4. When the end user tries to remove application B owning the shared
> library that is required for other installed applications, the
> platform should warn the user that designated applications would not
> work correctly if the library is removed.

I am afraid that maintaining proper UX in such case requires
uninstalation of B to be denied.

> 5. The platform should provide a naming service for the installed
> shared library so that any 3rd party application using it may locate
> and use (load) it without knowing the specific id of the owning
> package/application.

How the 3rd party libraries are ment to be loaded?

1) Are they going to available for dynamic linking with the system
linker (/lib/ld-linux.so)?

2) Is there going to be a separate linker/launcher for applications?

if 1) is True:

   How would you like to prevent 3rd parties from providing libraries
   that may override system libraries? This is a bad idea.

elif 2) is True:

   This looks like a great load of work.

else:

   Huh? (dlopen(3)? see below)

> Considerations
>
> 1. Library provider
>    1) Tizen app can be a library provider with specifying a tag and
>    embedding the libraries.
>    2) Library provider specifies a tag in the manifest file.
>       a) <ProvideLibrary>http://tizen.org/library/name</ProvideLibrary>
>       b) This tag can be restricted to partner and platform privilege
>          levels.
>    3) Libraries are located at /shared/res/ to share with other apps.

Does this suggest we are going to implement our own linker? (see below)

> 2. Library user
>    1) Library user specifies a tag in the manifest file.
>       a) <RequireLibrary>http://tizen.org/feature/library/name</RequireLibrary>
>    2) Library user has to check whether the library provider app has
>       been installed or not.
>       a) The library provider app is not installed, request of
>          installation is sent toStore client.

This is a task of package manager not the package itself. Upon
installation the library user is not a running code but rather a piece
of data.

> 3. Platform package manager
>    1) Installed apps from Store should be uninstalled anytime when
>       device user requests through the System settings.
>       a) Library provider app should be uninstalled anytime.
>       b) Deep relationship with library provider app and library user
>          is not recommended.

This is where the hound is burried. If it is possible it is going to
happen. If developers find it cheaper to develop apps this way, they
will.

>          Library user app can be working without library provider app,
>          if needed.

This means dlopen(3). Yet another degree of freedom for app developers
to break things and make Tizen look bad.

>    2) Package manager can extract information of provider and users
>       using manifest at installation time.

>       a) Package manager can display a warning popup to notify a
>          message.  i.e. “If this app is uninstalled, [AppB, AppC and
>          AppD] apps may not be working well.”
>       b) If the provider is uninstalled, the related user apps can be
>          terminated, if needed.

This isn't enough. Package manager MUST offer possibility to uninstall
AppB AND AppC AND AppD together with the package that provides required
library.

>    3) Application libraries are located in app directory and don’t be
>       moved to common library directory.
>       a) Library path is not specified in library user app.
>    4) Package Manager can support library path API using the key that
>       is specified in manifest.xml.

So the "app-libraries" are going to be plugins loaded with dlopen(3)
rather than linked dynamically with ld-linux.so. Am I right? This allows
for better security as 3rd party libraries won't be visible to
ld-linux.so but makes their usage much (maybe not that much) harder for
developers. Developers are going to need a tool that is going to make
loading libraries work a bit like under MS Windows (at least older
versions).

Under MS Windows to use a mylibrary.dll developer needs to obtain a
*static* mylibrary.lib and link it into her programm. The lib file
provides all the symbols exported by the dll files. Instead of
implementation it provides stubs that open load the dll file and links
its symbols to the stubs.

Again, technically this is possible but brings some mess. Unlike normal
ELF bineries which hold information about libraries the programme uses,
applications loading "app-libraries" via statically linked stubs won't
provide such information. The only way to learn it is going to be via
the package manager.

The way the libraries may be located (via package manager database) may
also incurr noticable preformance hit. There is a discussion on this
list about making applications start fast. And the difference between
950ms and 630ms is considered worth fighting for[1].

[1] https://lists.tizen.org/pipermail/dev/2013-October/000263.html
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131015/fa8931f2/attachment.sig>


More information about the Dev mailing list