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.
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...
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. 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
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.
make it work. That is wy MS Windows does not have a decent package
management. Most applications for Windows are not developed by Microsoft
and no one (Adobe, Altium, Autodesk, this is just the beginning of the
alphabed) would ever hand their code for Microsoft to recompile and
package. (I am not sure how the new Microsoft store works. Does it
require to you to give them your source?)
Appstore model is closer to windows model there is no "single
distribution point" but rather a "single storeage point". That is why,
I discourage distributing shared libraries via the 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
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
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
[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
--
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
