It was <2013-10-28 pon 00:19>, when Carsten Haitzler wrote: > 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.
Please take a look at how tpk[1] works today. >>>>>>> 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... What I worry about are not libraries and dependencies but rather everything else needed for AppStore. Linux package managers were hoped to be cross-platform. People at RedHat and Debian hoped it would be possible to build a package once and install it everywhere. This would be ideal for ISV. Today we know, this isn't possible. Every packaging system I know work reliably only in its native space. Sometimes you may succeed in installing Debian's packages on Ubuntu (or the other way round) but this is not a strict rule. This isn't just a matter of packaging this is how the software works. For example build your C++ libraries with a different compiler and it won't work. >>> 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. This isn't that much. The only things in RPM dependencies on my Ubuntu that I might have not installed otherwise (if I was seeking for a very low-profile system) are: Berkeley DB, lua, lzma, NSS. > 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 No we don't. We don't support RPM as a means of application distribution which, as I see it, is something completely different than distribution of bits of the platform. We most probably won't agree on this. >>>>> 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. How can an owner of a ppa specify which other ppa to use to install one of its dependencies? What if two ppa-s require the same library from two differnt ppa-s? Are you sure there is going to be a single Tizen 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 It works indeed. I use some ppa-s too. I am afraid, however, that this is not robust enough for unadministrated smart devices. The chance that something goes wrong is IMHO too high. >>> 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 > and/or This may be a little hard to tell. > 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 This looks workable. Yet, I still would like the extra libraries to be completely invisible to the system ld.so. As much I as dislike the dlopen(2) static stubs for loading system libraries (like Windows does) it looks nice for ISV provided libraries that (IMHO) need to be strictly separated from the system libraries. OK. I see your points and I admit that with some work put in it RPM could be used but you havn't convinced me enought to make me support this idea :-) >>>>>> [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 [1] https://developer.tizen.org/help/index.jsp?topic=%2Forg.tizen.native.appprogramming%2Fhtml%2Fbasics_tizen_programming%2Ftizen_app_model%2Fapplication_package_manager.htm -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgpXK7LTWE7qO.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
