6. Conventions for module Writers
Prev   

6. Conventions for module Writers

6.1. Exported Data

  • Type of exported data:

    Modules should only export data which is normally selected or entered by the user in normal module operation. No computed or automatically probed data should be exported.

  • Use Namespaces

    Exported variables should have a unique name when possible and when general terminology is being used. To avoid conflicts and confusion, use a name space identifier with common words. For example, if a module should export the variable name options, it is better to export <module name>.options to avoid confusion with other modules using options, which is very common in configurations.

  • Lower case variables

    To have a common and unified look of the control file, please use lower case variables when exporting the configuration data.

  • The structure of the exported data should be readable and not unnecessarly complex.

  • Avoid using configuration data as the key in a map key/value pair. The key of the pair must always contain the variable name, rather than it's contents

6.2. YaST2 Module Types

YaST2 configuration modules and in relation with AutoYaST can be put into three categories:

  1. Simple modules which mormally only change sysconfig variable and have simple configuration data structure. (i.e. mail, nis, ldap, etc.)

    This category needs no special attention and is easy to integrate with the AutoYaST.

  2. Simple modules dealing with hardware configuration (i.e. network, sound, printer etc.)

    These modules need to be able to read and autodetect hardware data during installation if no hardware data is specified in the control file. The behaviour of this type of modules up to 8.1 was to import data and write it wihtout actually reading anything from the system.

    An additional step has to be added between the import and the write, where hardware data is read and imported into the module. In some case this is simply done by calling the Read function the module.

  3. Modules for management of complex configuration files (i.e. inetd, sysconfig, runlevel, users, bootloader)

    This class of modules is much more complex and requires adaptation and special attention. AutoYaST expects that only new and modified entries will be exported and not the whole configuration tree. For example when a user enables a service in inetd, only this service is exported. A user should be able to add new services which are not available in the default configuration file too.

6.3. Module behaviour

In configuration mode for auto-installation, modules should not(configuration system is the machine where the control file is being created):

  • Read any data from the configuration system

  • Probe or detect hardware on the configuration system

  • Change configuration data on the configuration system

  • Offer a link to other modules (i.e. calling the NIS module from the users module)

  • Check if a needed package is installed on the configuration system.

Prev   
5. Configuration file Home