[Dev] 3rd party so library installation feature

Łukasz Stelmach l.stelmach at samsung.com
Thu Oct 17 08:44:54 GMT 2013

It was <2013-10-17 czw 04:42>, when Carsten Haitzler wrote:
> On 10/16/2013 09:43 PM, Łukasz Stelmach wrote:
>> It was <2013-10-16 śro 12:36>, when Carsten Haitzler wrote:
>>> On 10/16/2013 07:09 PM, Łukasz Stelmach wrote:
>>>> It was <2013-10-16 śro 06:56>, when Carsten Haitzler wrote:
>>>>> tpk or wgt packages should not PROVIDE/package shared libs/content.
>>>> I replied Dongeup Ham's mail yesterday but I focused on some other
>>>> aspects than package managment. I am curious why, in your opinion tpk
>>>> and wgt packages are not good medium to distribute shared libraries.
>>> to throw the q back to you - if tpk/wgt are so good - lets drop rpm
>>> and build tizen entirely with them.
>> [...]
>> Now, at the very moment, you can't use any of the formats for both:
>> applications and platform. There are missing bits on both sides. If one
>> wants libraries to be distributable via Tizen Store, the shortest route
>> is to use the tpk files. If it works in general, then changing package
>> format in Tizen 5.0, when we have our own zypper/yum/apt which we havn't
>> got now, and neither of them is well suited for end-users, especially
>> UX-wise, is trivial.
> what bits is rpm missing? there was a list of requirements sent. rpm
> meets all of them. tpk does not (no dependency handling for starters).

I assume this was a list of requirements for library distribution that
go beyond what tpk already provides. I don't know the full list of
features of tpk format and software that supports it.

Does RPM, as you know it today, support:

1. Signing with X509 certified keys?

2. Does it support application manifests[1]? Can rpm(8) interpret it?

>>>>> all you are doing is re-inventing rpm (or deb, or any one of a dozen
>>>>> other tools) but now instead stuffing it into tpk/wgt because rpm is
>>>>> "not invented here" and for the sake of quoting "policies like "but
>>>>> tizen store only handles tpk/wgt". that's just saying "but we invented
>>>>> a new standard because we didn't know how to use existing ones and now
>>>>> that we made that mistake we'll keep on making it because we can't
>>>>> re-evaluate our past decisions".
>>>> I mean, there are already a few pieces of the 3rd party software
>>>> distribution system (wrt-installer, osp-installer) that work quite
>>>> differently than rpm. Adding dependency handling, especially in short
>>>> term like Tizen 3.0 or even 4.0, seems to me a lot easier than adapting
>>>> RPM to handle requirements of application ecosystem.
>>> as per the original mail - nothing on the requirements list was not
>>> already handled by rpm - the same thing we already use for the os and
>>> is already enterprise tested and debugged (unlike tpk).
>> No other Linux distro has got an application store. Those who do plan to
>> have one (Gnome) do not consider RPM a viable choice[3]. I trust them.
> actually they do... ubuntu has one. :) just for starters. they use deb
> (disallowing scripts).

deb is not rpm. As much as I hate building Debian packages myself the
package format is much more flexible.

> gnome starts afresh with NO package system in its ecosystem thus for
> their position they don't ALREADY have rpm (or deb, or tpk etc.)
> there. and naturally they plan to roll their own. this is a common
> thing gnome does. if i were making an appstore for e i'd roll my own
> too - because i HAVE to make it work ON TOP of any existing
> distribution

You can bundle rpm, can't you?

>>> if i was saying we ADD rpm to tizen because we don't use it... that
>>> would be an entirely different matter. we already use it. it's
>>> there. just harness it as it stands.
>>> what i said was "don't do NIH - what you ask for is already there in rpm".
>>>> Technically it might even mean changing the format of RPM packages
>>>> because, not everybody knows this, there is a fixed list RPM headers[2]
>>>> which most probably does not meet the needs. (It does not meet the needs
>>>> of building our platform, IMHO)
>>> so the fact that rpm has been used to ship enterprise quality level os
>>> solutions for EVERY element of an os for almost 2 decades means that
>>> maybe it doesn't have all the fields that are needed for such a task?
>>> i beg to differ.
>> Then you may be wrong (as well as I may be wrong too, in fact we both
>> may be wrong). Appstores are completely different model than "enterprise
>> quality level os solutions". First, each vendor provides its product as
>> a repository (for yum, zypper etc.). You buy a licens you add a file in
>> /etc/zypp (or you do some clicking in YaST or whatever).  Having said
>> that, I am not sure RPM would fit in a different model. I do not say NO.
> how is an appstore different to how redhat, fedora (debian, ubuntu
> etc.) work. it is a "single distribution point". there is the added
> need of possibly a purchase. :)

The word distribution here is very, very tricky. All the distributions,
you've mentioned have their own QA teams/policies and those are the
companies' people who maintain the packages in that "single distribution
point". They can access the source code, they can patch it, they can
make it work. That is wy MS Windows does not have a decent package
management. Most applications for Windows are not developed by Microsoft
and no one (Adobe, Altium, Autodesk, this is just the beginning of the
alphabed) would ever hand their code for Microsoft to recompile and
package. (I am not sure how the new Microsoft store works. Does it
require to you to give them your source?)

Appstore model is closer to windows model there is no "single
distribution point" but rather a "single storeage point". That is why,
I discourage distributing shared libraries via the store.

>> RPM has a suprisingly limitted support for dependency description
>> compared to deb files[2]. Some of the missing dependency types are
>> crucial in a multi-vendor environment.
> a distribution as of today is a multi-vendor environment. almost every
> src pkg comes from a different vendor - a different project, and each
> one works slightly differently.

And is packaged by the organisation that builds the distro. That is what
makes it all work together. Tell me how many packages on your computer
come packaged for your distribution from a vendor other that the creator
of the distribution?

> in the end with shared libs (as was the topic) all the fields in the
> rpm linked to in [2] are pretty much superfluous because in the end
> linked lib resolving is done by ld.so

My brave man, belive me, you do not want the libraries downloaded from a
store to be even seen by ld.so unless you really want your X server to
use a custom implementation of fprintf(3) that can send your shoe size
as well as your credit card number to... [trrrrrrrrrrr, tik, tik,
tik...] Gabon.

>>>> [1] https://github.com/openSUSE/libsolv
>>>> [2]
>>>> http://rpm.org/gitweb?p=rpm.git;a=blob;f=lib/rpmtag.h;h=e8e9dee264f47e81c44a53108625ba3221e4e90f;hb=26389a69ac37f37dd35b12ef340316dc903b3955
>> [1] http://www.rpm.org/wiki/Releases/4.5.90
>> [2] http://www.rpm.org/wiki/DynamicDependencies
>> [3] https://mail.gnome.org/archives/gnome-os-list/2012-August/msg00002.html
[1] https://developer.tizen.org/help/index.jsp?topic=%2Forg.tizen.native.appprogramming%2Fhtml%2Fide_sdk_tools%2Fmanifest_element_hierarchy.htm
Ł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/20131017/545d22e2/attachment.sig>

More information about the Dev mailing list