[Dev] 3rd party so library installation feature

Carsten Haitzler c.haitzler at samsung.com
Sun Oct 27 23:19:48 GMT 2013

On 10/17/2013 05:44 PM, Łukasz Stelmach wrote:
> 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.

i was assuming that the list of requirements was... the list of 
requirements. :)

> 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?

neither of these were in the requirements list.

>>>>>> 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.

and that assumes it needs to change at all to handle shared libs and 
dependencies, which it seems perfectly capable of as even WE use it to 
build tizen...

>> 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?

but then you also bring it its dependencies and take on support. if 
you're going to have to support something - better you wrote it OR have 
people "on staff" who know it really well. as such we are supporting rpm 
already anyway, so the price is already paid

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

ppa's. the distro has zero control as above. and they work. they work as 
well as the maintainer bothers to make them work and that has nothing to 
do with package format at all as ONCE installed a shared lib is divorced 
from its packaging. it's files the runtime linker has to deal with or 
the shared lib itself.

> 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?

see above. ppa's. it's not a single build point once you start using 
ppa's for libs the  distro does not provide. of the software i use day 
to day.. MOST of it doesn't come from the distro vendor. at least most 
in terms of function and effect to me. it's self-compiled over in /usr/local

>> 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.

then there is no point allowing shared libs as that is the WHOLE POINT 
of having them... to have the dynamic linker find them. for security 
reasons it's easy enough to make this work:

1. reject shared lib pkgs that conflict/override existing system libs
2. $LD_LIBRARY_PATH is set for apps wishing to use extra installed 
shared libs so they ADD the extar shared lib dir to search path

>>>>> [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

The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.

More information about the Dev mailing list