Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
en:cookbook:receipt [2010/08/21 17:52] – update (again) lineaen:cookbook:receipt [2017/04/24 15:05] (current) – [Functions] hgt
Line 2: Line 2:
  
  
-This document describes the opportunities offered by the recipes used by Tazwok to compile and generate packages for SliTaz and Tazpkg through The wok and tools. The recipe for a package is also used by Tazpkg to install/uninstall and provide information about a .tazpkg package. Each recipe begins with a comment in English:+This document describes the opportunities offered by the recipes used by Cookutils to compile and generate packages for SliTaz and Tazpkg through the wok and tools. The recipe for a package is also used by Tazpkg to install/uninstall and provide information about a .tazpkg package. Each recipe begins with a comment in English:
  
-<file># SliTaz package receipt </file>+<file bash># SliTaz package receipt </file>
  
 ===== Variables ===== ===== Variables =====
Line 10: Line 10:
  
 The first 5 variables should always be present and defined. They respectively configure the package ($PACKAGE), its version, its category, provide a short description and the name of the maintainer. Example for the package, file manager Clex: The first 5 variables should always be present and defined. They respectively configure the package ($PACKAGE), its version, its category, provide a short description and the name of the maintainer. Example for the package, file manager Clex:
-<file>+<file bash>
 PACKAGE="clex" PACKAGE="clex"
 VERSION="3.16" VERSION="3.16"
Line 21: Line 21:
  
  
-Tazwok also knows how to use various optional variables. It can, for example, use the name of another source package. There are also variables that are used by Tazpkg to manage dependencies or provide information about the package.+Cookutils also knows how to use various optional variables. It can, for example, use the name of another source package. There are also variables that are used by Tazpkg to manage dependencies or provide information about the package.
  
-  * **$DEPENDS:** Set dependencies, there may be several dependencies seperated by a space or on several lines. This variable is used mainly by Tazpkg when installing the package and Tazwok to build large packages such as Xorg. Example for Clex which depends on ncurses:+  * **$DEPENDS:** Set dependencies, there may be several dependencies separated by a space or on several lines. This variable is used mainly by Tazpkg when installing the package and Cookutils to build large packages such as Xorg. Example for Clex which depends on ncurses:
  
-<file>DEPENDS="ncurses"</file>+<file bash>DEPENDS="ncurses"</file>
  
-  * **$BUILD_DEPENDS:** Set compilation dependencies, again seperated by a space or several lines. This variable is used by Tazwok during the cooking of a package. Example:+  * **$BUILD_DEPENDS:** Set compilation dependencies, again separated by a space or several lines. This variable is used by Cookutils during the cooking of a package. Example:
  
-<file>BUILD_DEPENDS="ncurses-dev"</file>+<file bash>BUILD_DEPENDS="ncurses-dev"</file>
  
   * **$TARBALL :** The archive is a source with the extension (tar.gz, tgz or tar.bz2). In general, the variables $PACKAGE and $VERSION are used to just change the extension, it helps to upgrade the package without changing the $VERSION variable. Generic example (see also $SOURCE example):   * **$TARBALL :** The archive is a source with the extension (tar.gz, tgz or tar.bz2). In general, the variables $PACKAGE and $VERSION are used to just change the extension, it helps to upgrade the package without changing the $VERSION variable. Generic example (see also $SOURCE example):
  
-<file>TARBALL="$PACKAGE-$VERSION.tar.gz"</file>+<file bash>TARBALL="$PACKAGE-$VERSION.tar.gz"</file>
  
-  * **$WEB_SITE :** The official website of the package. It may be that some libraries have no website, in this case, there is no need to specify a URL. Note Tazwok and Tazpkg both expect to find a URL with the complete HTTP: +  * **$WEB_SITE :** The official website of the package. It may be that some libraries have no website, in this case, there is no need to specify a URL. Note Cookutils and Tazpkg both expect to find a URL with the complete HTTP: 
  
-<file>WEB_SITE="http://www.clex.sk/"</file>+<file bash>WEB_SITE="http://www.clex.sk/"</file>
  
-  * **$WGET_URL :** URL to download the source file. In general the variable $TARBALL should be used to facilitate the updating of the package without changing the $VERSION. Using a configuration file, Tazwok also configures by default 3 mirrors: $GNU_MIRROR for the GNU mirror, $SF_MIRROR for SourceForge and XORG_MIRROR for mirroring the graphical server Xorg. Example for Clex:+  * **$WGET_URL :** URL to download the source file. In general the variable $TARBALL should be used to facilitate the updating of the package without changing the $VERSION. Using a configuration file, Cookutils also configures by default 3 mirrors: $GNU_MIRROR for the GNU mirror, $SF_MIRROR for SourceForge and XORG_MIRROR for mirroring the graphical server Xorg. Example for Clex:
  
-<file>WGET_URL="http://www.clex.sk/download/$TARBALL"</file>+<file bash>WGET_URL="http://www.clex.sk/download/$TARBALL"</file>
  
   * **$CONFIG_FILES :** Some packages provide customized configuration files. The $CONFIG_FILES variable provides a list of these files that can be saved by the 'tazpkg repack-config' command. These files are not overwritten when reinstalling the package if they already exist and the package can be successfully recreated with 'tazpkg repack', (even if they have been modified since). Netatalk for example:   * **$CONFIG_FILES :** Some packages provide customized configuration files. The $CONFIG_FILES variable provides a list of these files that can be saved by the 'tazpkg repack-config' command. These files are not overwritten when reinstalling the package if they already exist and the package can be successfully recreated with 'tazpkg repack', (even if they have been modified since). Netatalk for example:
  
- <file>CONFIG_FILES="/etc/netatalk/AppleVolumes.* /etc/netatalk/*.conf"</file>+ <file bash>CONFIG_FILES="/etc/netatalk/AppleVolumes.* /etc/netatalk/*.conf"</file>
  
   * **$SUGGESTED :** Lists useful packages without being essential. Also used to activate optional features.   * **$SUGGESTED :** Lists useful packages without being essential. Also used to activate optional features.
Line 51: Line 51:
   * **$WANTED :** SliTaz packages normally depend on the compilation of a source package. Sometimes the recipe of a package requires no compilation of rules, then $WANTED is used to copy files from the source of another package by using the variable $ src.   * **$WANTED :** SliTaz packages normally depend on the compilation of a source package. Sometimes the recipe of a package requires no compilation of rules, then $WANTED is used to copy files from the source of another package by using the variable $ src.
  
-  * **$SOURCE :** It may be that the Tazpkg package name differs from the name of the source package. Example for Xorg packages, the name of Tazpkg library X11 is 'xorg-libX11' and the name of the package source is libX11. $SOURCE allows you to use the variables $src and $_pkg during the cooking of a package. It should be noted that in the case of libX11, the name of the source archive becomes $SOURCE-$VERSION.tar.gz.+  * **$SOURCE :** It may be that the Tazpkg package name differs from the name of the source package. Example for Xorg packages, the name of Tazpkg library X11 is 'xorg-libX11' and the name of the package source is libX11. $SOURCE allows you to use the variables $src and $install during the cooking of a package. It should be noted that in the case of libX11, the name of the source archive becomes $SOURCE-$VERSION.tar.gz.
  
-  * **$PROVIDE :** Some packages offer the same functionality, for instance the web server was at first lighttpd; now apache is available. All packages dependent on a web server refer to lighttpd. The //PROVIDE="apache"// variable in the apache recipe states that packages dependent on lighttpd do not need to install the lighttpd package if apache is already on the system. Some packages may vary according to the webserver you choose, ie. the php package is dependent on lighttpd, as is php-apache on apache. The //PROVIDE="php:apache"// in the apache recipe says that you must install php-apache instead of php, if apache is already on the system. Therefore each package dependent on php will install either php-apache or php according to the webserver on the system. This variable also chooses packages compiled with different options. The //PROVIDE="epdfview:cups"// in the epdfview-cups recipe allows you to install epdfview with printer support via cups if cups is already on the system. \\+  * **$PROVIDE :** Some packages offer the same functionality, for instance the web server was at first lighttpd; now apache is available. All packages dependent on a web server refer to lighttpd. The //PROVIDE="lighttpd"// variable in the apache recipe states that packages dependent on lighttpd do not need to install the lighttpd package if apache is already on the system. Some packages may vary according to the webserver you choose, ie. the php package is dependent on lighttpd, as is php-apache on apache. The //PROVIDE="php:apache"// in the apache recipe says that you must install php-apache instead of php, if apache is already on the system. Therefore each package dependent on php will install either php-apache or php according to the webserver on the system. This variable also chooses packages compiled with different options. The //PROVIDE="epdfview:cups"// in the epdfview-cups recipe allows you to install epdfview with printer support via cups if cups is already on the system. \\
 You can also define virtual packages with this variable. The lines //PROVIDE="libgl"// in the mesa package and //PROVIDE="libgl:nvidia"// in the ''nvidia-glx'' package, define that libgl is an optimized version when the nvidia package is installed. You can also define virtual packages with this variable. The lines //PROVIDE="libgl"// in the mesa package and //PROVIDE="libgl:nvidia"// in the ''nvidia-glx'' package, define that libgl is an optimized version when the nvidia package is installed.
  
-  * **$SELF_INSTALL :** Certain packages use commands provided by the package itself in the post_install function. To install this package into a directory other than root and still be able to use these commands, the package must have been installed in / in earlier stages. The line: //SELF_INSTALL=1// alerts tazpkg to this feature. +  * **$SELF_INSTALL (obsolete):** Certain packages use commands provided by the package itself in the post_install function. To install this package into a directory other than root and still be able to use these commands, the package must have been installed in / in earlier stages. The line: //SELF_INSTALL=1// alerts tazpkg to this feature. This variable is depreciated. The command __//chroot "$1/" a_package_command//__ in post_install does the job.
  
-===== Variables generated by Tazwok =====+===== Variables generated by Cookutils =====
  
-Certain factors are known only during the cooking of a package or after the package has been cooked. Tazwok will add them to the recipe automatically.+Certain factors are known only during the cooking of a package or after the package has been cooked. Cookutils will add them to the recipe automatically.
  
   * **$PACKED_SIZE :** Tazpkg file size.   * **$PACKED_SIZE :** Tazpkg file size.
Line 66: Line 66:
   * **$UNPACKED_SIZE :** Space taken up by the package after installation.   * **$UNPACKED_SIZE :** Space taken up by the package after installation.
  
-  * **$EXTRAVERSION :** Some packages have 2 different versions. This is in case of modules added to the Linux kernel, such as squashfs, because the module depends on the version of the kernel with which it was compiled. In this case $EXTRAVERSION contains the kernel version and Tazwok determines the module from the contents of **/lib/modules**.+  * **$EXTRAVERSION :** Some packages have 2 different versions. This is in case of modules added to the Linux kernel, such as squashfs, because the module depends on the version of the kernel with which it was compiled. In this case $EXTRAVERSION contains the kernel version and Cookutils determines the module from the contents of **/lib/modules**.
  
 ===== Variables used in functions ===== ===== Variables used in functions =====
  
-Tazwok configures several variables that facilitate the compilation and construction of Tazpkg packages. These variables are controlled automatically by Tazwok using the information contained in the recipe; they can be used by the functions compile_rules and genpkg_rules described in the chapter Functions.+Cookutils configures several variables that facilitate the compilation and construction of Tazpkg packages. These variables are controlled automatically by cookutils using the information contained in the recipe; they can be used by the functions compile_rules and genpkg_rules described in the chapter Functions.
  
   * **$src :** Defines the path to the directory of unarchived sources.   * **$src :** Defines the path to the directory of unarchived sources.
  
-  * **$_pkg :** Defines the path to the compiled binaries installed via 'make DESTDIR=$PWD/_pkg install'. This variable is used to copy the generated files and create Tazpkg packages.+  * **$install :** Defines the path to the compiled binaries installed via 'make DESTDIR=$DESTDIR install'. This variable is used to copy the generated files and create Tazpkg packages. 
 +   
 +  * **$_pkg :** Same as $install.
  
   * **$fs :** Defines the path to the pseudo filesystem (fs) in each package. The 'fs' of the package corresponds to the root of the system, a bit like Clex will for example be in $fs/usr/bin/clex. Note the need to create the necessary directories via function genpkg_rules() before copying the files.   * **$fs :** Defines the path to the pseudo filesystem (fs) in each package. The 'fs' of the package corresponds to the root of the system, a bit like Clex will for example be in $fs/usr/bin/clex. Note the need to create the necessary directories via function genpkg_rules() before copying the files.
  
-  * **$CONFIGURE_ARGS :** This variable is defined in the Tazwok configuration file (tazwok.conf). It allows you to specify generic optimization arguments during construction of a package. Default is the i486 architecture. +  * **$CONFIGURE_ARGS :** This variable is defined in the cookutils configuration file (cook.conf). It allows you to specify generic optimization arguments during construction of a package. Default is the i486 architecture.  
 +   
 +  * **$DESTDIR : ** Defines the path to install compiled binaries after the build via 'make DESTDIR=$DESTDIR install'.
  
 ===== Functions ===== ===== Functions =====
  
-A recipe may contain 4 functions. Tazwok knows how to deal with functions containing compilation rules (compile_rules) and rules used to generate a package (genpkg_rules). These functions may contain all sorts of GNU/Linux standard commands, such as sed, awk, patch and variables automatically configured.+A recipe may contain 4 functions. Cookutils knows how to deal with functions containing compilation rules (compile_rules) and rules used to generate a package (genpkg_rules). These functions may contain all sorts of GNU/Linux standard commands, such as sed, awk, patch and variables automatically configured.
  
 === compile_rules() === === compile_rules() ===
  
-To compile a package you can use the variable $src to move (cd) in the directory of sources and use $CONFIGURE_ARGS to include arguments from the Tazwok configuration file. To build the package you usually launch 'make' without any arguments, and to install the package into the directory _pkg: it's necessary to use the command 'make DESTDIR=$PWD/_pkg install'. Generic example:+To compile a package you can use the variable $src to move (cd) in the directory of sources and use $CONFIGURE_ARGS to include arguments from the Cookutils configuration file. To build the package you usually launch 'make' without any arguments, and to install the package into the directory ''$DESTDIR'': it's necessary to use the command ''make DESTDIR=$DESTDIR install''. Generic example:
  
-<file>+<file bash>
 # Rules to configure and make the package. # Rules to configure and make the package.
 compile_rules() compile_rules()
Line 96: Line 100:
  --mandir=/usr/share/man $CONFIGURE_ARGS  --mandir=/usr/share/man $CONFIGURE_ARGS
  make  make
- make DESTDIR=$PWD/_pkg install+ make DESTDIR=$DESTDIR install (or simply make install)
 } }
 </file> </file>
Line 102: Line 106:
 === genpkg_rules()=== === genpkg_rules()===
  
-To generate a tazkg package we must specify commands in the function genpkg_rules. In this example we create a psuedo directory usr/ in the filesystem of the package, copy the whole binary(s) and finally use strip to clean the files:+To generate a tazkg package we must specify commands in the function genpkg_rules. In this example we create a psuedo directory /usr in the filesystem of the package, copy the whole binary(s) and finally use strip to clean the files:
  
-<file>+<file bash>
 # Rules to gen a SliTaz package suitable for Tazpkg. # Rules to gen a SliTaz package suitable for Tazpkg.
 genpkg_rules() genpkg_rules()
 { {
  mkdir -p $fs/usr  mkdir -p $fs/usr
- cp -a $_pkg/usr/bin $fs/usr+ cp -a $install/usr/bin $fs/usr
  strip -s $fs/usr/bin/*  strip -s $fs/usr/bin/*
 } }
Line 116: Line 120:
 === pre_install() and post_install()=== === pre_install() and post_install()===
  
-These functions are initiated by Tazpkg when installing the package. They must be defined before generating the .tazpkg package with Tazwok. If no rules are given for these functions, they have no raison d'etre and can be removed. Example using echo to display some text (no function should be empty):+These functions are initiated by Tazpkg when installing the package. They must be defined before generating the .tazpkg package with Cookutils. If no rules are given for these functions, they have no raison d'etre and can be removed. Example using echo to display some text (no function should be empty):
  
-<file>+<file bash>
 # Pre and post install commands for Tazpkg. # Pre and post install commands for Tazpkg.
 pre_install() pre_install()
Line 132: Line 136:
 === pre_remove() and post_remove() === === pre_remove() and post_remove() ===
  
-These functions are initiated by Tazpkg when removing the package. They must be defined before generating the .tazpkg package with Tazwok. If no rules are given for these functions, they have no raison d'etre and can be removed. Example using echo to display some text (no function should be empty):+These functions are initiated by Tazpkg when removing the package. They must be defined before generating the .tazpkg package with Cookutils. If no rules are given for these functions, they have no raison d'etre and can be removed. Example using echo to display some text (no function should be empty):
  
-<file>+<file bash>
 # Pre and post remove commands for Tazpkg. # Pre and post remove commands for Tazpkg.
 pre_remove() pre_remove()
Line 145: Line 149:
 } }
 </file> </file>
- 
-=== clean_wok() === 
- 
-This function helps to define additional commands to be run when cleaning the wok, it is useful to delete files or directories that are not supported by Tazwok: 
- 
-<file> 
-# clean commands for Tazwok. 
-clean_wok() 
-{ 
- rm -rf $WOK/$PACKAGE/vim71 
-} 
-</file> 
- 
 
en/cookbook/receipt.1282413133.txt.gz · Last modified: by linea