[Dev] 3rd party so library installation feature

Carsten Haitzler c.haitzler at samsung.com
Wed Oct 16 10:36:27 GMT 2013


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.

>> 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. what's so great about rpm that we need 
it to build our os when tpk obviously is good enough. if its good enough 
for 3rd party pkgs then its good enough for the os (3rd parties will 
need the same features... maybe minus scripts). then we can also write 
up all the documentation as to how to build shared libs, deal with 
things like auto-dependency generation and so on too. sounds good. let's 
do that. why should we need to learn how to use multiple packaging 
systems and suffer the bloat of having multiple installed on devices 
when one is enough? tpk it is! :)

>> 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). 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. only thing we don't have is yum/apt on top to fetch.

> [1] https://github.com/openSUSE/libsolv
> [2] http://rpm.org/gitweb?p=rpm.git;a=blob;f=lib/rpmtag.h;h=e8e9dee264f47e81c44a53108625ba3221e4e90f;hb=26389a69ac37f37dd35b12ef340316dc903b3955

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