[Dev] 3rd party so library installation feature

Carsten Haitzler c.haitzler at samsung.com
Thu Oct 17 02:42:10 GMT 2013


On 10/16/2013 09:43 PM, Łukasz Stelmach wrote:
> It was <2013-10-16 śro 12:36>, when Carsten Haitzler wrote:
>
> tl;dr
>
> Package format is not cucial for App distributed libraries and RPM may
> have some issues in this model. It can be changed after solving more
> important problems.

format is not curcial - but re-inventing what is already there is not a 
great way to go. :)

>> On 10/16/2013 07:09 PM, Łukasz Stelmach wrote:
>>> It was <2013-10-16 śro 06:56>, when Carsten Haitzler wrote:
>>>> what i am saying is "you should use rpm for managing the libraries and
>>>> dependencies". the job is already done.the toolis already part of tizen.
>>>> it's there. it's tested.use it.
>>> To be precies, it is not RPM that manages dependencies but rather
>>> libsolv[1]. RPM itself can do very little for solving dependencies. The
>>> best it can do is check if the dependencies are satisfied.
>> and that requires we gather and pass all given data to libsolv and
>> re-implement the interfacing code. i don't think that is relevant
>> here.
> Yes.
>
>>>> 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).

>>>> 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). 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 whose packaging system is unknown and unable to be 
controlled, harnessed or recycled. that is NOT the case with tizen. ([3] 
makes zero mention of rpm in any way... just search the page for rpm 
comes up with nothing).

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

> I talked with RPM guys from RedHat and SuSE in February. Thay said thay
> need to change the format in a number of ways. Starting with the archive
> format (this probably isn't an issue on Tizen) because cpio can't handle
> files larger than 4GiB[1]. They also said that the way headers are
> handeled today: *all* the headers from rpm files go to the database, is
> not right. They discussed how to limit the database size by excluding
> some fields.

and so why use rpm for the base os then due to the fields? if its so 
poor at handling the smaller set of libraries and/or 3rd party apps that 
will get installed on a device (the # of pkgs added later by a user is 
dwarfed by the # of pkgs already on the system) ?

4gb is maybe a problem - but it was not included in the requirements. if 
a 3rd party library needs 4gb of pkg... seriously we have bigger 
problems. it's no longer a library. android had the problem of apks 
limited to a few mb ... and that was easily handled by simply having an 
installer as the pkg then downloading the rest. we do it for the tizen 
sdk already. but seriously - if we have pkgs that hit the multi-gb size 
we will have MAJOR problems as users have to download all that data and 
without all the "restart your download from where it left off" handling, 
as well as probably distributed download mechanisms, we're in trouble. 
for such vast pkg sizes it probably is better to split it up into core 
(which should easily fit into the mb's not gb's) and then "data" as a 
separate fetch.

> 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. 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 and 
it is rather simplistic... so it's more a matter of keeping off 
eachothers toes at the .so level and then simply indicating your 
dependencies that you can't sensibly function without (and of course 
there are recommends and suggests which are more than enough).

as a result of having done shared libs now for a long time, i've come to 
the conclusion through experience and history, that having 
suggests/recommends is already too much. people simply ignore 
suggestions. unless you make it a requirement people will just skip it, 
so in the end even if you can function without, make your optional 
dependencies hard ones - otherwise you just spend forever educating 
people (as people don't use documentation nor do they tend to take 
dialogs/warnings too seriously).

> To sum it up. RPM is becoming not good enough for "enterprise quality
> level os solutions" that is why i think we should keep using two
> different packaging systems for two different distribution channels.
>
>> only thing we don't have is yum/apt on top to fetch.
> <nitpicking>
> If you ask me, I don't want neither of these because they don't use
> libsolv (which IMHO is the most efficient solution at the moment). There
> is Fedora's WIP dnf-to-be-renamed-to-yum but it's not ready yet. If we
> want something mature then it is opensuse's zypper.
> </nitpicking>

i just don't want to ad-hoc rebuild/re-invent what already is in rpm et 
al and stuff it into tpkg etc. when we already use/have rpm there. :)

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

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