[Dev] 3rd party so library installation feature

Łukasz Stelmach l.stelmach at samsung.com
Wed Oct 16 12:43:00 GMT 2013


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.

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

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

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

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.

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.

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>

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

-- 
Ł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/20131016/9ce30b7c/attachment.sig>


More information about the Dev mailing list