<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 22. Porting an Application</title><meta name="generator" content="DocBook XSL Stylesheets V1.71.1"><link rel="start" href="index.html" title="A-A-P Recipe Executive"><link rel="up" href="user.html" title="Part II. User Manual"><link rel="prev" href="user-python.html" title="Chapter 21. Using Python"><link rel="next" href="user-configure.html" title="Chapter 23. Automatic Configuration"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><table width="100%" id="navtable"><tbody><tr><td align="left" class="left" width="33%"><b><a href="http://www.a-a-p.org">A-A-P home page</a></b></td><td align="center" class="center" width="34%"><b><a href="index.html">A-A-P Recipe Executive</a></b></td><td align="right" class="right" width="33%"></td></tr><tr><td align="left" class="left"><a accesskey="p" href="user-python.html">Prev</a></td><td align="center" class="center">User Manual</td><td align="right" class="right"><a accesskey="n" href="user-configure.html">Next</a></td></tr></tbody></table><hr><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="user-porting"></a>Chapter 22. Porting an Application</h2></div></div></div><p>
Porting an application means starting with the original sources and
changing them a little bit to make the application compile and install on a
specific system. An <span class="application">Aap</span> port recipe offers a simple way to create a port,
because all the standard work does not need to be specified.
</p><p>
NOTE: not all features mentioned here fully work. Make sure you test your
port recipe before publishing it.
</p><h2><a name="id2650364"></a>The Port Recipe</h2><p>
The basic idea is that you assign values to a number of predefined
variables. <span class="application">Aap</span> will then generate the steps for building and installing
the package, using the values you have specified. The presence of the
"PORTNAME" variable triggers <span class="application">Aap</span> to handle the recipe as a port recipe.
The list of variables is in the next section.
</p><p>
This is thee list of steps performed when executing <span class="application">Aap</span> without arguments,
in this order:
</p><div class="informaltable"><table border="0"><colgroup><col width="150"><col></colgroup><tbody><tr><td>dependcheck</td><td>early check to see if dependencies can be met; abort without
doing anything if something is known to fail</td></tr><tr><td>fetchdepend</td><td>handle dependencies for fetch and checksum</td></tr><tr><td>fetch</td><td>get the required files</td></tr><tr><td>checksum</td><td>check if the files have correct checksums</td></tr><tr><td>extractdepend</td><td>handle dependencies for extract and patch</td></tr><tr><td>extract</td><td>unpack archives</td></tr><tr><td>patch</td><td>apply patches</td></tr><tr><td>builddepend</td><td>handle dependencies for configuring and building</td></tr><tr><td>config</td><td>do pre-building configuration</td></tr><tr><td>build</td><td>build</td></tr><tr><td>testdepend</td><td>handle dependencies for testing</td></tr><tr><td>test</td><td>check if building was done properly</td></tr><tr><td>package</td><td>create a binary package</td></tr><tr><td>install</td><td>install the binary package</td></tr><tr><td>rundepend</td><td>handle runtime dependencies</td></tr><tr><td>installtest</td><td>test if the package fully works and was installed properly</td></tr></tbody></table></div><p>
For each step a dependency with build commands is added. The purpose of
each step is further explained below.
</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><table border="0" summary='Note: Meaning of "dependency"'><tr><td rowspan="2" align="center" valign="top" width="25"><img alt="[Note]" src="images/note.png"></td><th align="left">Meaning of "dependency"</th></tr><tr><td align="left" valign="top"><p>
The term "dependency" is ambiguous here. You should be able to guess from
the context whether it is used for a dependency of one software package on
another package, or a dependency of a target file on a source file.
</p></td></tr></table></div><p>
You can do part of the work by starting <span class="application">Aap</span> with one of the step names.
The steps before it will also be executed if necessary.
For example, "aap package" will do all the steps necessary to generate the
binary package but not install it.
</p><p>
If your port requires non-standard stuff, you can specify your own
build commands. You can replace the normal step, prepend something to it
and append something to it:
</p><div class="informaltable"><table border="0"><colgroup><col width="150"><col></colgroup><tbody><tr><td>do-XXX</td><td>replace the body of a step</td></tr><tr><td>pre-XXX</td><td>do something before a step</td></tr><tr><td>post-XXX</td><td>do something after a step</td></tr></tbody></table></div><p>
</p><p>
Example:
</p><pre class="programlisting">
post-test:
# delete the directory used for testing
:del {r}{f} $WRKDIR/testdir
</pre><h2><a name="id2652219"></a>Variables</h2><p>
Various variables need to be set to specify properties of the port.
</p><div class="informaltable"><table border="0"><colgroup><col width="200,300"><col><col></colgroup><thead><tr><th>variable</th><th>used for</th><th>example value</th></tr></thead><tbody><tr><td>PORTNAME</td><td>name of the port</td><td>"foobar"</td></tr><tr><td>PORTVERSION</td><td>app version number</td><td>"3.8alpha"</td></tr><tr><td>PORTREVISION</td><td>port patchlevel (optional)</td><td>"32"</td></tr><tr><td>CVSMODULES</td><td>names of CVS modules to checkout (optional)</td><td>Exec</td></tr><tr><td>MAINTAINER_NAME</td><td>maintainer name (optional)</td><td>John Doe</td></tr><tr><td>MAINTAINER</td><td>maintainer e-mail (optional)</td><td>john@foobar.org</td></tr><tr><td>PORTCOMMENT</td><td>short description </td><td>get foo into the bar</td></tr><tr><td>PORTDESCR </td><td>long description</td><td>blah blah blah</td></tr><tr><td>IS_INTERACTIVE</td><td>requires user input (optional)</td><td>yes or no</td></tr></tbody></table></div><p>
</p><p>
Variables that can be used by the port recipe:
</p><div class="informaltable"><table border="0"><colgroup><col width="200"><col><col><col></colgroup><thead><tr><th>variable</th><th>used for</th><th> </th><th>default value</th></tr></thead><tbody><tr><td>WRKDIR</td><td>directory all files are extracted in and the building is done
in</td><td> </td><td>"work"</td></tr><tr><td>DISTDIR</td><td>directory where downloaded distfiles are stored</td><td> </td><td>"distfiles"</td></tr><tr><td>PATCHDISTDIR</td><td>directory where downloaded patches are stored</td><td> </td><td>"patches"</td></tr><tr><td>PKGDIR</td><td>directory where files are stored before creating a
package</td><td> </td><td>"pack"</td></tr></tbody></table></div><p>
</p><p>
Variables that may be set by the port recipe, defaults are set only after
reading the recipe:
</p><div class="informaltable"><table border="0"><colgroup><col width="200"><col><col></colgroup><thead><tr><th>variable</th><th>used for</th><th>default value</th></tr></thead><tbody><tr><td>WRKSRC</td><td>Directory inside $WRKDIR where the unpacked sources end up. This
should be the common top directory in the unpacked archives.
When using CVS it is always set to $CVSWRKSRC (also
when $WRKSRC was already set).</td><td>$PORTNAME-$PORTVERSION</td></tr><tr><td>CVSWRKSRC</td><td>Directory inside $WRKDIR where files
obtained with CVS end up.</td><td>the first entry in $CVSMODULES</td></tr><tr><td>PATCHDIR</td><td>Directory inside $WRKDIR where patches are to be
applied. Can be overruled for a specific patch with a "patchdir"
attribute.</td><td>$WRKSRC</td></tr><tr><td>BUILDDIR</td><td>Directory inside $WRKDIR where building is to be
done.</td><td>$WRKSRC</td></tr><tr><td>TESTDIR</td><td>Directory inside $WRKDIR where testing is to be done.</td><td>$WRKSRC</td></tr><tr><td>INSTALLDIR</td><td>Directory inside $WRKDIR where $INSTALLCMD is to be
done.</td><td>$WRKSRC</td></tr><tr><td>CONFIGURECMD</td><td>Set to the command used to configure the application. Usually
"./configure".</td><td>nothing</td></tr><tr><td>BUILDCMD</td><td>Set to the command used to build the application. Usually
just "make".</td><td>"aap"</td></tr><tr><td>TESTCMD</td><td>Set to the command used to test the application. Usually
"make test".</td><td>"aap test"</td></tr><tr><td>INSTALLCMD</td><td>Set to the command used to do a fake install of the
application.</td><td>"aap install DESTDIR=$PKGDIR"</td></tr></tbody></table></div><p>
</p><h2><a name="id2652650"></a>Dependency Format</h2><p>
Dependencies on other modules are specified with the various DEPEND_
variables. The format of these variables is a list of items.
</p><p>
NOTE: Although you can currently specify dependencies, the code for checking
them has not been implemented yet! Thus the user will have to figure it out
by himself...
</p><p>
Items are normally white space separated, which means there is an "and"
relation between them. Alternatively "|" can be used to indicate an "or"
relation.
</p><pre class="programlisting">
DEPENDS = perl python # require both perl and python
DEPENDS = perl | python # require perl or python
</pre><p>
Parenthesis can be used to group items. Parenthesis must be used when
combining "or" and "and" relations. Example:
</p><pre class="programlisting">
DEPENDS = (foo bar) | foobar # Either both "foo" and "bar" or "foobar"
DEPENDS = foo bar | foobar # Illegal
DEPENDS = foo (bar | foobar) # "foo" and either "bar" or "foobar"
</pre><p>
When a dependency is not met the first alternative will be installed, thus the
order of "or" alternatives is significant.
</p><p>
Each item is in one of these formats:
</p><div class="informaltable"><table border="0"><colgroup><col width="250"><col></colgroup><tbody><tr><td>name-version_revision</td><td>a specific version and revision</td></tr><tr><td>name</td><td>any version</td></tr><tr><td>name-regexp</td><td>a version specified with a regular expression (shell
style)</td></tr><tr><td>name>=version_revision</td><td>any version at or above a specific version and revision</td></tr><tr><td>name>version_revision</td><td>any version above a specific version and revision</td></tr><tr><td>name<=version_revision</td><td>any version at or below a specific version and revision</td></tr><tr><td>name<version_revision</td><td>any version below a specific version and revision
name!version_revision any version but a specific version and
revision</td></tr></tbody></table></div><p>
</p><p>
In the above "_revision" can be left out to ignore the revision number. It
actually works as if there is a "*" wildcard at the end of each item.
</p><p>
"name" can contain wildcards. When a part is following it is appended at the
position of the wildcard (or at -9 if it comes first).
</p><div class="informaltable"><table border="0"><colgroup><col width="150"><col></colgroup><tbody><tr><td>foo-*</td><td>matches foo-big, foo-big-1.2 and foo-1.2</td></tr><tr><td>foo-*!1.2</td><td>matches foo-big, foo-big-1.2 and skips foo-1.2</td></tr></tbody></table></div><p>
</p><p>
The version specifications can be concatenated, this creates an "and"
relation. Example:
</p><div class="informaltable"><table border="0"><colgroup><col width="200"><col></colgroup><tbody><tr><td>foo>=1.2<=1.4</td><td>versions 1.2 to 1.4 (inclusive)</td></tr><tr><td>foo>=1.2!1.8</td><td>versions 1.2 and above, excluding 1.8</td></tr><tr><td>xv>3.10</td><td>versions above 3.10, accepts xv-3.10a</td></tr></tbody></table></div><p>
</p><p>
The "!" can be followed by parenthesis containing a list of specifications.
This excludes the versions matching the specifications in the parenthesis.
Example:
</p><div class="informaltable"><table border="0"><colgroup><col width="200"><col></colgroup><tbody><tr><td>foo>=1.1!(>=1.3<=1.5)</td><td>versions 1.1 and higher, but not versions 1.3 to 1.5</td></tr><tr><td>foo>=6.1!6.1[a-z]*</td><td>version 6.1 and later but not 6.1a, 6.1rc3, etc.</td></tr></tbody></table></div><p>
</p><p>
When a dependency is not met the newest version that meets the description is
used.
</p><p>
For systems that do not allow specifying dependencies like this in a binary
pacakge, the specific package version that exists when generating the package
is used.
</p><h2><a name="id2652995"></a>Dependencies For Various Steps</h2><p>
The various variables used to specify dependencies:
</p><div class="informaltable"><table border="0"><colgroup><col width="200"><col></colgroup><tbody><tr><td>DEPEND_FETCH</td><td>Required for fetching files. Also for computing
checksums.</td></tr><tr><td>DEPEND_EXTRACT</td><td>Required for unpacking archives.</td></tr><tr><td>DEPEND_BUILD</td><td>Required for building but not necessarily for running; these are not
included in the binary package; items may also appear in
DEPEND_RUN.</td></tr><tr><td>DEPEND_TEST</td><td>Required for testing only; don't include items that are already in
DEPEND_RUN.</td></tr><tr><td>DEPEND_RUN</td><td>Required for running; these will also be included in the generated
binary package.</td></tr><tr><td>DEPENDS</td><td>Used for DEPEND_BUILD and DEPEND_RUN when empty.</td></tr></tbody></table></div><p>
</p><p>
Only the dependencies specified with DEPEND_RUN will end up in the generated
binary package. When using a shared library, it is recommended to put a
dependency on the developer version (includes header files) in DEPEND_BUILD
and a dependency on the library itself in DEPEND_RUN. The result is that when
installing binary packages the header files for the library don't need to be
installed.
</p><p>
The "CONFLICTS" variable should be set to specify modules with which this one
conflits. That means only one of the two packages can be installed in the
same location. It should still be possible to install the packages in
different locations. The format of CONFLICTS is identical to that of the
DEPENDS_ variables.
</p><p>
NOTE: Although you can currently specify dependencies and conflicts, the code
for checking them has not been implemented yet! Thus the user will have to
figure it out by himself...
</p><p>
Dependencies are automatically installed, unless "AUTODEPEND" is "no".
The dependencies are normally satisfied by installing a port. When a
satisfying port can not be found a binary package is installed.
The ports and packages are first searched for on the local system. When not
found the internet is searched.
</p><p>
The order of searching can be changed with "AUTODEPEND":
</p><div class="informaltable"><table border="0"><colgroup><col width="300"><col></colgroup><tbody><tr><td>binary</td><td>only search for binary packages, default locations</td></tr><tr><td>source</td><td>only search for ports, default locations</td></tr><tr><td>source {path = /usr/ports http://ports.a-a-p.org}</td><td>only search for ports in /usr/ports and on the ports.a-a-p.org
web site.</td></tr></tbody></table></div><p>
</p><h2><a name="id2653216"></a>Steps</h2><p>
These are the individual steps for installing a ported application. Each step
up to "install" depends on the previous one. Thus "aap install" will do all
the preceding steps. But the steps that have already been successfully done
in a previous invocation of <span class="application">Aap</span> will be skipped. The "rundepend",
"installtest", "clean", etc. targets do not depend on previous steps, they can
be used separately.
</p><div class="variablelist"><dl><dt><span class="term">
dependcheck
</span></dt><dd><p>
Check if required dependencies can be fulfilled.
</p><p>
This doesn't install anything yet, it does an early check if building
and/or installing the port will probably work before starting to
download files.
</p><p>
This uses all the DEPEND_ variables that will actually be used.
Fails if something is not available.
</p></dd><dt><span class="term">
fetchdepend
</span></dt><dd><p>
Check dependencies for fetch and checksum.
</p><p>
Uses DEPEND_FETCH, unless disabled with AUTODEPEND=no
</p></dd><dt><span class="term">
fetch
</span></dt><dd><p>
Get required files.
</p><p>
If $CVSMODULES is set and $CVS is not "no", obtain files from CVS:
</p><table class="simplelist" border="0" summary="Simple list"><tr><td> Uses $CVSROOT or cvsroot attribute in $CVSMODULES.</td></tr><tr><td>$CVSWRKSRC is where the files will end up (default is first
member in $CVSMODULES).</td></tr><tr><td>Also obtain $CVSDISTFILES if defined.</td></tr><tr><td>Also obtain $CVSPATCHFILES if defined.</td></tr><tr><td>Use a post-fetch target if directories need to be renamed.</td></tr></table><p>
else
</p><table class="simplelist" border="0" summary="Simple list"><tr><td>if $DISTFILES is set obtain them</td></tr><tr><td>if $PATCHFILES is set obtain them</td></tr></table><p>
Use MASTER_SITES for [CVS]DISTFILES.
Use PATCH_SITES for [CVS]PATCHFILES.
The [CVS]DISTFILES are put in $DISTDIR.
The [CVS]PATCHFILES are put in $PATCHDISTDIR.
</p><p>
The directory can be overruled with a {distdir = dir} attribute on
individual patch files.
</p><p>
Files that already exist are skipped (if there is a checksum error,
delete the file(s) manually).
</p></dd><dt><span class="term">
checksum
</span></dt><dd><p>
Check if checksums are correct.
</p><p>
The port recipe writer must add the "do-checksum" target with
<a href="ref-commands.html#cmd-checksum">:checksum</a> commands to verify that
downloaded files are not
corrupted. Example:
</p><pre class="programlisting">
# >>> automatically inserted by "aap makesum" <<<
do-checksum:
:checksum $DISTDIR/foo-1.1.tgz {md5 = 2341423423423423434}
:checksum $PATCHDISTDIR/foo-patch3.gz {md5 = 3923858739234}
# >>> end <<<
</pre><p>
The "aap makesum" command can be used to generate the lines.
</p></dd><dt><span class="term">
extractdepend
</span></dt><dd><p>
Check dependencies for extract and patch.
</p><p>
Uses DEPEND_EXTRACT, unless disabled with AUTODEPEND=no
</p></dd><dt><span class="term">
extract
</span></dt><dd><p>
Unpack archives in the right place.
Use $EXTRACT_ONLY if defined, otherwise $DISTFILES or
$CVSDISTFILES when CVS was used.
</p><p>
Uses the "extract" action. To extract a new type of archive:
</p><table class="simplelist" border="0" summary="Simple list"><tr><td> add filetype detection for this type of archive</td></tr><tr><td> define an "extract" action for this filetype </td></tr></table><p>
</p><p>
Extraction is done in $WRKDIR. A subdirectory may be specified with
the "extractdir" attribute on each archive.
</p><pre class="programlisting">
DISTFILES = foo-1.1.tgz foo_doc-1.1.tgz {extractdir = doc}
</pre></dd><dt><span class="term">
patch
</span></dt><dd><p>
Apply patches not applied already.
</p><p>
$PATCHCMD defines the patch command, default: "patch -p < ".
The patch file name is appended, unless "%s" appears in the
string, then it's replaced by the file name.
</p><p>
A "patchcmd" attribute on each patch file may specify a patch command
that overrules $PATCHCMD.
</p><p>
The patches are applied in $WRKDIR/$PATCHDIR (default: $WRKSRC).
A "patchdir" attribute on each patch file may overrule the value of
$PATCHDIR.
</p></dd><dt><span class="term">
builddepend
</span></dt><dd><p>
Check dependencies for configure and build.
</p><p>
Uses DEPEND_BUILD, unless disabled with "AUTODEPEND=no".
</p></dd><dt><span class="term">
config
</span></dt><dd><p>
Perform configuration.
</p><p>
Executes the command specified with CONFIGURECMD. Usually
autoconf, imake, etc. May be empty.
</p></dd><dt><span class="term">
build
</span></dt><dd><p>
Run the command specified with BUILDCMD. When empty "aap" is used.
Useful values are "gmake", "make", etc. An argument may be included.
Example: "BUILDCMD=make foo"
</p><p>
Done in $WRKDIR/$BUILDDIR, default: $WRKDIR/$WRKSRC
</p></dd><dt><span class="term">
testdepend
</span></dt><dd><p>
Check test dependencies.
</p><p>
Uses DEPEND_TEST.
</p><p>
check if all required items are present
try to install them automatically, unless disabled AUTODEPEND=no
This is skipped when "SKIPTEST=yes"
</p></dd><dt><span class="term">
test
</span></dt><dd><p>
Check if building was done properly.
</p><p>
Executes TESTCMD. When it is empty "aap test" is used. Example:
"TESTCMD=make testall"
</p><p>
This is skipped when "SKIPTEST=yes"
Done in $WRKDIR/$TESTDIR, default: $WRKDIR/$WRKSRC
</p></dd><dt><span class="term">
package
</span></dt><dd><p>
Create a package with selected files, usually including the compiled
program.
</p><p>
There are two methods to select files to be included in the package:
</p><div class="orderedlist"><ol type="1"><li><p>
Specify the list of files below $WRKDIR, with a "dest" attribute
where they should end up. Assign the list to $PACKFILES.
Example:
</p><pre class="programlisting">
PACKFILES = $WRKSRC/bin/prog {dest = /usr/local/bin/prog}
$WRKSRC/man/prog.1 {dest = usr/local/man/man1/prog.1}
</pre><p>
</p></li><li><p>
Specify a command to fake-install into $PKGDIR and use all files
that end up there.
Set $INSTALLCMD to the command to be used. Example:
</p><pre class="programlisting">
INSTALLCMD = "aap install DESTDIR=$PKGDIR"
</pre><p>
Set INSTALLDIR to the directory inside $WRKDIR where the files
are put. Default is $WRKSRC. $PKGDIR/$PREFIX is where files
end up.
</p></li></ol></div><p>
</p><p>
A packing list is generated with the files that exist in the package.
Then "pkg_create" is executed to actually create the package.
Arguments are given such that $PORTDESCR is used as the
description of the package and $PORTCOMMENT for a short explanation of
what the package is for.
</p></dd><dt><span class="term">
install
</span></dt><dd><p>
Install the binary package.
</p><p>
This executes the "pkg_add" command in a separate shell.
You are asked to type the root password.
This is reasonably safe, since the shell is only connected to Aap and
it can only install a package.
</p><p>
Exception: This updates the "rundepend" and "installtest" targets
after updating the post-install target. This allows doing "aap
install", which is a lot more obvious than "aap installtest".
</p></dd><dt><span class="term">
rundepend
</span></dt><dd><p>
Check runtime dependencies.
</p><p>
Check if all required items specified with $DEPEND_RUN are present and
tries to install them automatically, unless $AUTODEPEND is "no".
</p><p>
This is skipped if $SKIPRUNTIME is "yes". The pre-rundepend and
post-rundepend are still done, they should check $SKIPRUNTIME
themselves.
</p><p>
"aap rundepend" will _not_ cause previous steps to be updated.
</p></dd><dt><span class="term">
installtest
</span></dt><dd><p>
Test if the installed package works.
</p><p>
This is empty by default, specify a "do-installtest" target to
actually do something.
</p><p>
Note that when $SKIPRUNTIME is "yes" the dependencies have not been
verified and running the application might not work.
</p></dd><dt><span class="term">
uninstall
</span></dt><dd><p>
Uninstall the binary package.
Not implemented yet!
</p><p>
Execute pkg_delete or equivalent.
Does not depend on other steps.
</p></dd><dt><span class="term">
clean
</span></dt><dd><p>
Delete all generated, unpacked, patched and CVS files.
</p><p>
Does not delete the downloaded files.
Does not depend on other steps.
Does not clean packages this one depends on.
</p></dd><dt><span class="term">
distclean
</span></dt><dd><p>
Delete everything except the toplevel recipe.
After this all steps must be redone.
</p><p>
Does not depend on other steps.
Does not clean packages this one depends on.
</p></dd><dt><span class="term">
makesum
</span></dt><dd><p>
Generates a "do-checksum" dependency that checks if the fetched files
were not corrupted.
</p><p>
If the recipe already contained a "do-checksum" dependency that was
generated it is replaced. Otherwise a new one is appended.
Do not change the markers before and after the "do-checksum"
dependency, otherwise you end up with two of these when doing "aap
makesum" again.
</p><p>
Does not depend on other steps. The files must already be present.
You can use "aap fetch --nofetch-recipe" to obtain the files, if
needed (it obtains the files but not the recipes).
</p></dd><dt><span class="term">
srcpackage
</span></dt><dd><p>
Generate a package with recipe and source files.
Not implemented yet!
</p><p>
Puts the main recipe and all downloaded files into an archive. The
resulting archive can be installed without downloading.
</p><p>
Depends on the "fetch" target.
</p></dd></dl></div><h2><a name="id2653870"></a>Port Description</h2><p>
The text to describe the port is usually a page full of plain text. Here is an
example:
</p><pre class="programlisting">
PORTDESCR << EOF
This is the description of the port.
A very important application indeed.
See our website http://myport.org.
EOF
</pre><p>
In the rare situation that "EOF" actually appears in the text you can use
anything else, such as "THEEND".
</p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="user-python.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="user.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="user-configure.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 21. Using Python </td><td width="20%" align="center"><a accesskey="h" href="index.html">
Contents</a></td><td width="40%" align="right" valign="top"> Chapter 23. Automatic Configuration</td></tr></table></div></body></html>
distrib
>
Mandriva
>
2010.0
>
i586
>
media
>
contrib-release
>
by-pkgid
>
a6d417e36f6bb1154f4c003e6717e298
>
files
>
161
