Per Package Modifications

Inside a target it is easy to supply per package modifications. Patches to the package's source code, such as new features or fixes, can simply be dropped into the target directory with the name pkg_$pkg.patch, for example target/$targetname/pkg_apache.patch. As usually the patches will be included in the package build and applied automatically by the build system.

When you have to alter the package build further, for example changing configure options, manipulate install paths and so on, you can overwrite the package configuration file by creating one named pkg_$pkg.conf in your target directory and supply the required configuration options. However, if you want to inherit the configuration as defined in the package itself you have to source the files manually:

# source the original file (if any)
[ -e $confdir/$pkg.conf ] && . $confdir/$pkg.conf

# special adaptations for the XYZ target
var_append confopt ' ' '--enable-some-fancy-feature'

Since this facility does not allow to alter the actual version and download location of the package, since T2 version 7.0 it is furthermore possible to completely overlay and inherit packages. This is usually useful if an architecture patch is only available for a special GCC or Linux kernel release, or maybe even so new to be a snapshot release. Also special requirements like an older PHP, MySQL, Wine, etc. version due to incompatible features in the current T2 version might be a reason to force a specific known good or certified version in a target.

Defining a target specific version is identical to creating a normal T2 package, but just inside a target's directory named target/$targetname/package/$pkg, like target/$targetname/package/apache/. Inside this directory the normal files, such as $pkg.desc, $pkg.conf, and patches can be placed. The exact semantic behaviour is: