On 2015-05-06 09:57, Carsten Haitzler wrote: > i kind of think that it's not worth chasing. 1 app == 1 package. that is all > upgraded/installed/uninstalled together. it CAN indstall multiple binaries > (multiple executables and thus icons to launch - this one package. it could > also installl just data files or shared libs or something else with no > binaries at all). > > as long as: > > 1. apps can be installed in $HOME as a user id by that user id with no > special root permissions we're fine. > 2. apps live entirely within their directory - any symlinks to data outside > an app dir is managed by tools outside of the app itself (catch - i might > point at freedesktop.org for where to put cache and config files like > ~/.cache and ~/.config - but a bit late for that now - i'd also have just > suggested we have .desktop files... but anyway - ignore this). > 3. app install dirs can be moved anywhere in the filesystem and the app must > continue to work (if launched again there). > > i think this should be sufficient. for now at least. hybrid aps will just > have to update both ends at the same time.
This isn't that simple. I'm trying to support hybrid apps constructed from two parts from different application frameworks. Like in the old Tizen2.x, where hybrid apps were formed by WRT and OSP parts.Those parts were installed separately, by two dedicated installers that didn't know about each other. My understanding of the whole concept of pkgId and appId is that you can have multiple applications (appIds) for a single package. And application framework guys can go crazy like wanting those apps to be installed independently or even idependently uninstalled, upgraded or added. Securityframework in Tizen 3 was designed to be ready for such requirements, even if they aren't needed at the moment.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
