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.

_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Reply via email to