Hi WonYoung, Thanks for your really interesting reply.
See my comments below in blue There is a weekly call on this topic with Poland Samsung Team to manage the development of app installer framework I let you see with this Team , if you are interesting to join this task Thanks BR Baptiste 2014-11-19 9:01 GMT+01:00 최원영 <[email protected]>: > Hello Baptiste Durand, > > > > I'm a WRT guy in Samsung. I want to discuss about steps of your new > installer. > > I think the steps should be divided more, because we have to consider > other installation modes (eg. FOTA, CSC, PRELOAD, RDS..). > Could you describe all acronym or abbreviation of rhe installation mode mentioned in a wiki page? CSC is not clear for me, because in the code of slp-pkgmgr is not linked to a backend installer... there is no call to a backend for this request : PM_REQUEST_CSC . Could tell us more about these modes? We are writting an app_installer as backend for pkgmgr-server to manage package for installation / uninstallation / upgrade etc... > Small step operations could be reused in these modes more easily. > > > This is also my point of view I thinks we are globally in sync. > I just reorganized steps roughly. Please see below contents. > > > > BRs, > > WonYoung Choi > > > -------------------------------------------------------------------------------------------- > CASE: INSTALL > // tempdir > #step create_tmpdir > #abort_step remove_tmpdir > > // read config > #step read_config > > // read signature > #step read_signatures > #step check_author_signature > #step check_cert_level > > // prepare > #step check_available_space > #step backup_installed_package > #abort_step restore_installed_package > #step kill_running_apps > I thinks there is no needs in case of package installation For uninstallation case (here there is a need) It is already handled in the pkgmgr-server code : look the CAPI pkgmgr_client_usr_uninstall So step for kill_running apps is not relevant > // install > #step create_pkgdir > #step_abort remove_pkgdir > #step install_files > #step create_symlink_for_execution > > // register > #step generate_manifest > #step_abort remove_manifest > #step register_manifest > #step_abort unregister_manifest > #step register_signatures > #step_abort unregister_signatures > > // encrypt > #step encrypt_resources > > // security > #step set_smack_labels > #step_abort revoke_smack_labels > > // finish > #step clean_up > > > CASE: REINSTALL (RDS) > #step read_config > #step read_signatures > #step check_author_signature > #step kill_running_apps > #step install_files_for_rds > #step register_signatures > #step encrypt_resources > #step set_smack_labels > > CASE: FOTA > ... > CASE: CSC > ... > CASE: PRELOAD > ... > > > -------------------------------------------------------------------------------------------- > > InstallContext { > tmpdir, /* temporary directory */ > src, /* source path */ > config, /* widget config object */ > author_signature, /* author signature object */ > distributor_signature[], /* array of distributor signature objects */ > cert_level, /* Unknown/Public/Partner/Platform */ > files, /* array of installed file path */ > This part of your answers is not clear. You mention this step # backup_installed_package depends: config It is not totally true, This step is not called during installation but only during upgrade of a package So this will be only depends of the type of the request : pkgmgr-server should determine this before execute backend. For me it is not the role of a backend to determine if it is in a upgrade case or install case. It should be handled by pkgmgr-server . Install = PKGMGR_REQ_INSTALL: Uninstall = PKGMGR_REQ_UNINSTALL: Upgrade = PKGMGR_REQ_UPGRADE. > } > > ## steps > > # create_tmpdir > depends: N/A > output: tmpdir > > create a temporary directory for installation. > eg. $HOME/.tmp/{auto_generated_id} > > # remove_tmpdir (abort) > depends: tmpdir > > remove the temporary directory. > > # read_config > depends: tmpdir, src > output: config > > Read and parse the widget configuration file, and make a widget config > object. > If 'src' path has below file extension, > 1) .wgt: extract config.xml to the temp dir and read it. > 2) .xpk: extract manifest.json to the temp dir and read it. > 3) .xml: read it > * XML schema validation with .xsd file is needed > I thoutght that it is already done. pkgmgr-info package : ./parser/ manifest.xsd.in This file is used by parser library > # read_signatures > depends: tmpdir, src > output: author_signature, distributor_signature[] > > Read and parse the signature files, and make signature objects. > If 'src' path has below file extension, > 1) .wgt: extract signature files to the temp dir and read it. > 2) .xpk: extract signature files to the temp dir and read it. > If 'src' path is a directory (in case of RDS), > read signature files in the specific directory. > * XML schema validation with .xsd file is needed. > > # check_author_signature > depends: author_signature > > If the package having 'config.pkgid' is already installed, Old > author-signature of the installed package and > new author-signature of the new package should be compared. > If these signatures are different, the installation process should be > aborted. > > # check_cert_level > depends: config, distributor_signatures[] > output: cert_level > > Detect the certification level with the distributor signatures and check > the widget configuration. > Some attributes and elements and privileges of the widget config require > the partner level or over. > > # check_available_space > depends: src > > Check available space to install new package. > If the 'src' path is a compressed file, consider the uncompressed size of > the package. > > # backup_installed_package > depends: config > > If the package having 'config.pkgid' is already installed, the installed > package should be moved to > the backup location. > eg. $HOME/.config/xwalk_service/applications/{pkgid}/ ==> > $HOME/.config/xwalk_service/applications/{pkgid}.backup/ > > # restore_installed_package (abort) > depends: config > > If the backup directory for the installed package is exist, restore it. > eg. $HOME/.config/xwalk_service/applications/{pkgid}.backup/ ==> > $HOME/.config/xwalk_service/applications/{pkgid}/ > > # kill_running_apps > depends: config > > If the applications of the installed package are running, these should be > killed before installation. > As I already said before, I don't fully agree with you for me it is true for uninstallation case only and it is already done in pkgmgr_client_usr_uninstall > # create_pkgdir > depends: config > > Create a directory to install new package. > eg. $HOME/.config/xwalk_service/applications/{pkgid} > Ok for the proposition execpt for the PATH , FYI the path is the one currently used but it is not aligned witht the spec. => https://wiki.tizen.org/wiki/Application_framework#Application_Paths # remove_pkgdir > depends: config > > Remove the created package directory. > eg. $HOME/.config/xwalk_service/applications/{pkgid} > > # install_files > depends: src, config > output: files > > Extract files from the package file to the created package directory. > if the package is > 1) a packaged web app, extract files to > $HOME/.config/xwalk_service/applications/{pkgid}/res/wgt/ > 2) a hosted web app, copy the .xml file to > $HOME/.config/xwalk_service/applications/{pkgid}/res/wgt/ > 3) a hybrid web app, extract files to > $HOME/.config/xwalk_service/applications/{pkgid}/ > > And make a list of installed files. > > # install_files_for_rds > depends: src, config > output: files > > In case of RDS, the SDK pushes changed files and a delta file to a temp > dir. > This step should read and parse the delta file first, and copy the > changed files to the path of the > installed package or remove removed files from the path. > And make a list of installed files. > > # create_symlink_for_execution > depends: config > > Create a directory for execution files. > eg. $HOME/.config/xwalk_service/applications/{pkgid}/bin/ > Create a symbolic link file to indicate 'xwalk_launcher' > eg. {appid} -> /usr/bin/xwalk_launcher > > > # generate_manifest > depends: config > > Generate the manifest file for the package-manager with the widget > configuration. > eg. $HOME/.applications/manifest/{pkgid}.xml > > > # remove_manifest (abort) > depends: config > > Remove the manifest file of the package. > eg. $HOME/.applications/manifest/{pkgid}.xml > > # register_manifest > depends: config > > Register the generated manifest file to the package-manager. > > # unregister_manifest (abort) > depends: config > > Unregister the registered manifest from the package-manager. > > # register_signatures > depends: config, author_signature, distributor_signature[] > > Register signatures to the package-manager. > > # unregister_signatures > depends: config > > Unregister signatures from the package-manager. > > # encrypt_resources > depends: config, files > > If the "encryption" attribute of <setting> element has "enabled" value, > The installed files should be ecrypted. > > # set_smack_labels > I'm affraid I don't agree on this step : security manager should handle this part. in independent way. It should be systematic to secure installation process for all kind of app. # set_smack_labels ===> set security_manager_calls > depends: config > > Set smack labels to directories of the installed package. > Set smack rules with privileges of the widget configuration. > > # revoke_smack_labels > depends: config > > remove smack labels and rules of the package. > > # clean_up > depends: tmpdir > > remove the temporary directory and the backup directory. > > > > > > > > ------- *Original Message* ------- > > *Sender* : Baptiste Durand<[email protected]> > > *Date* : 2014-11-19 02:41 (GMT+09:00) > > *Title* : [Dev] App installers package > > > Hi all, > > As reminder, the goal of this package is to provide a set of function to > implement easily a installer for every type of applications on Tizen.( i.e > wgt/xpk and native app tpk). > > The git repository for this new package is stored here : > platform/appfw/app_installers > > > As decided with Samsung Team led by Pawel Sitorsky, the C++ language will > be preferred to C language. > As the package should be aligned with the global architecture of Tizen, ( > https://wiki.tizen.org/w/images/2/2c/Architecture_Overview_.jpg) CAPI > should be used to access to a platform service. So we need to wrap them > because CAPI are mainly written in C. > > > > The proposal is described here : > https://wiki.tizen.org/wiki/Applications_Installer#Implementation_concept > > The idea is to be able to initialize easily an app_installer by declare a > list of step as below : > > > for widget as example > int > main (int argc, char **argv) > { > int result; > AppInstaller Installer = new AppInstaller(); > /* get request data */ > pi = pkgmgr_installer_new (); > if (!pi) > return ENOMEM; > result = pkgmgr_installer_receive_request (pi, argc, argv); > if (result) > { > pkgmgr_installer_free (pi); > return -result; > } > > /* treat the request */ > switch (pkgmgr_installer_get_request_type (pi)) > { > case PKGMGR_REQ_INSTALL: > Installer->AddStep(step_unpack); > Installer->AddStep(step_check_signature); > Installer->AddStep(step_check_wgt); > Installer->AddStep(step_manifest_wgt); > Installer->AddStep(&step_register_app); > Installer->Run(); > break; > > case PKGMGR_REQ_UNINSTALL: > ............. > > > default: > /* unsupported operation */ > result = EINVAL; > break; > } > pkgmgr_installer_free (pi); > return result; > } > > > Any point fo view are welcomed on this architecture. > > Thanks in advance > BR > > Baptiste > -- > Baptiste DURAND > Eurogiciel Vannes/FR > > -- Baptiste DURAND Eurogiciel Vannes/FR
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
