When building IIPs the following is a normal workflow:
For each IIP do the following:
There a number of things to consider when dividing your things into one or more IIPs:
Different parts of what you have built may have different requirements on the architecture of the IP-STB. Some parts may be for a specific processor while other parts may work on all kinds of IP-STBs. It may then be a good idea to make two different IIPs. An example of this is the HTML application which is divided into one application installation package, which contains platform independant scripts and XML files, and one application registration package which contains the platform specific binaries and libraries. platforms.
It is desirable to be able to use the IIPs in different configurations. All IIPs should be "atomic" to make sure that you only get what you want when installing an IIP in a boot image, i.e. they should only contain one part that can work on its own. Don't put several applications into one IIP.
It is however possible to use the parameter possiblity of the build_boot_image command to only install parts of an IIP. It can then be a good idea to gather things with common characteristics into one IIP. The kreatv-option-streamclients is a good example of this since it is almost never desirable to have all stream clients at once in a boot image, but it would not be a good idea to have 14 different IIPs either.
In some cases the order in which parts are installed is important. Then the different parts can be put in different IIPs.
A special feature of the IIP concept called finalization can also be used to make an IIP be installed after all normal IIPs. It can be a good idea to divide your things into one normal IIP and one finalization IIP. The finalization IIP would then have the complete boot image to work on which can be needed in special cases.
The kreatv-inst-browser package requires that its components are registered after installation. But since there are other packages that modifies the browser installation these packages would have to redo the registration. An easier thing to do is to have a kreatv-finalize-browser IIP which does the registration after all normal IIPs have been installed. The various IIPs that modifies the browser installation does not have to worry at all about registration and are thus easier to maintain.
There are a number of things that could be stored in the data directory. Things that shall be installed, scripts to be run when installing the IIP and data that shall be used during the installation.
The layout of the data depends on its intended usage:
In this case it is easiest to use the same layout in the data dir as in the rootdisk. You can then use the copy_data_to_rootdisk installation script which will copy the data into the rootdisk at build time.
This can also be done at runtime and the script to be used then is the move_data_at_runtime.sh installation script.
In some cases it it easier to make one IIP that only installs some of its files depending on the parameters used when installing it. A typical example is the kreatv-option-streamclients IIP which installs one or more stream clients.
In this case you can use any layout of the data directory that you desire and let the installation script install it in the correct place in the rootdisk. You must also write your own installation script to make this work.
Some IIPs only modifies the rootdisk, a typical example is the kreatv-tool-logging IIP which creates a file in the /etc directory based on the parameters given to the IIP.
In this case it is not necessary to have a data directory (it would be empty) so don't create one.
An IIP must contain a number of installation scripts (at least one) to be used in different environments.
The buildtime installation script is used to install IIPs in a rootdisk at build time (i.e. when building the rootdisk/boot image). The build_boot_image script which combines IIPs into rootdisks and boot images allows parameters to be sent to the installation script. The parameters can be used for a number of things:
The runtime installation script is used to install
IIPs at runtime using KreaTV Dynamic Download. This script is
e.g. required for dynamic boot loader IIPs as well as for IIPs
belonging to dynamically downloable applications. Several runtime
installation scripts can be used for the same IIP. If so, they will be
appended to each other into one script in the order specified in the
argument list given to the iip_build script.
An IIP may contain an uninstallation script if it should be possible to uninstall it at runtime.
The runtime uninstallation script is used to uninstall IIPs at runtime with KreaTV Dynamic Download. This script is e.g. used in IIPs belonging to dynamically downloadable applications.
An IIP may depend on that one or more other IIPs are installed. If you have divided your parts into more than one IIP you must specify the relationship between them. For example an application registration package may require that the application installation package is installed, which in turn requires that the KreaTV TV Application Platform is installed.
The build_boot_image command makes sure that the IIPs is installed in the correct order if the dependencies are correct.
If the boot image is configured to support application download and a number of applications are configured to be installed after booting the IP-STB, these applications' installation IIPs will be excluded from the boot image and will be installed when starting the applications (or at boot). These IIPs may depend on other IIPs not installed in the boot image, such as IIPs holding libraries. All of these IIPs has to be made available for dynamic download. See the Operation and Maintenance Guide for more information on this.
Note! Circular dependencies are strictly forbidden, they will cause the KreaTV IP-STB to fail.
More about dependencies can be found in the IIP attributes page.
Finalizers are a special kind of dependency that must also be specified.