Author: emap
Date: Sat Nov 5 17:30:39 2011
New Revision: 66716
URL: http://svn.opensuse.org/viewcvs/yast?rev=66716&view=rev
Log:
edited by emap
Modified:
trunk/autoinstallation/doc/xml/SoftwareSection.xml
Modified: trunk/autoinstallation/doc/xml/SoftwareSection.xml
URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/SoftwareSection.xml?rev=66716&r1=66715&r2=66716&view=diff
==============================================================================
--- trunk/autoinstallation/doc/xml/SoftwareSection.xml (original)
+++ trunk/autoinstallation/doc/xml/SoftwareSection.xml Sat Nov 5 17:30:39 2011
@@ -24,19 +24,18 @@
<section id="Software.Selections.sles10">
<title>
- Package Selections with patterns
+ Package Selections with Patterns
</title>
<para>
- SLES10 no longer supports <emphasis>selections</emphasis> but uses
- <emphasis>patterns</emphasis> now. Autoyast is not be able to convert
- selections into patterns and so you have to do that on your own.
- If you want to use a SLES9 autoyast profile to install a SLES10
- server, you have to remove all <emphasis>addon</emphasis> entries and the
- <emphasis>base</emphasis> entry. Patterns are configured like this:
+ SLES10 no longer supports <emphasis>selections</emphasis> but uses
+ <emphasis>patterns</emphasis>. &ay; cannot convert selections to
+ patterns. If you want to use a SLES9 &ay; profile to install a SLES10
+ server, you have to remove all <emphasis>addon</emphasis> entries and
+ the <emphasis>base</emphasis> entry. Patterns are configured like this:
</para>
<example>
<title>
- Package selection in control file with patterns
+ Package Selection in Control File with Patterns
</title>
<screen>
http://192.168.66.6/SLES10/sdk/CD1
-http://192.168.66.6/SLES10/CD1/updates
+ media_url is the URL of the media, path_on_media is the path to the
+ catalog on the media. If not present, / (root) is assumed. product_1
+ and following are the names of products, which should be marked for
+ installation. If no product is specified, all products found on the
+ media are selected for installation. For example: </para><screen>
+ http://192.168.66.6/SLES10/sdk/CD1
+ http://192.168.66.6/SLES10/CD1/updates
</screen>
<para>
- Besides that <emphasis>add_on_products</emphasis> file, you can use the autoyast profile to specify add-on products. For example:
+ Besides the <emphasis>add_on_products</emphasis> file, you can use the &ay; profile to specify add-on products. For example:
</para>
<screen>
<add-on>
@@ -163,19 +158,19 @@
</add-on>
</screen>
<para>
- With that entry in the autoyast profile, the <emphasis>add_on_products</emphasis> file is not necessary.
- Since openSUSE 11.0 AutoYaST can ask the user to make the add-on available intead of reporting a timed out error when the add-on can't be found at the given location. Set ask_on_error to true for that (the default is false).
- Your add-on can be on a different CD/DVD than the installation source then.
+ With this entry in the &ay; profile, the <emphasis>add_on_products</emphasis> file is not necessary.
+ Since openSUSE 11.0, &ay; can ask the user to make add-on products available instead of reporting a time-out error when an add-on product cannot be found at the given location. Set ask_on_error to "true" (the default is "false").
+ Then your add-on product can be on a different CD/DVD than the installation source.
</para>
<para>
- YaST checks the signatures of files on the installation source now. If a <emphasis>content</emphasis> file is
- not signed, during a manual installation YaST asks the user what to do. During an autoinstallation, the
- installation source gets rejected silently.
+ &yast; checks the signatures of files on the installation source. If a <emphasis>content</emphasis> file is
+ not signed, during a manual installation &yast; asks the user what to do. During an automatic installation, the
+ installation source is rejected silently.
</para>
</note>
<para>
- If you want to use unsigned installation sources with autoyast, you can turn of the checks with the following
- configuration in your autoyast profile (part of the <emphasis>general</emphasis> section.
+ If you want to use unsigned installation sources with &ay;, turn off the checks with the following
+ configuration in your &ay; profile (part of the <emphasis>general</emphasis> section.
</para>
<para>
The following elements must be between the <general><signature-handling> ... </signature-handling></general> tags.
@@ -192,53 +187,53 @@
<tbody>
<row>
<entry>accept_unsigned_file</entry>
- <entry><para>the installer will accept unsigned files like the content file</para>
+ <entry><para>If set to "true", &ay; will accept unsigned files like the content file.</para>
<para><literal><accept_unsigned_file config:type="boolean">true</accept_unsigned_file></literal></para>
</entry>
- <entry>optional. If left out, autoyast lets yast decide what to do</entry>
+ <entry>Optional. If left out, &ay; lets &yast; decide what to do.</entry><remark>emap 2011-11-05: Is this correct? How will YaST make the decision? Above we write that YaST will ask the user, but during auto-install the package will be rejected. So which is it?</remark>
</row>
<row>
<entry>accept_file_without_checksum</entry>
- <entry><para>the installer will accept files without a checksum in the content file</para>
+ <entry><para>If set to "true", &ay; will accept files without a checksum in the content file.</para>
<para><literal><accept_file_without_checksum config:type="boolean">true</accept_file_without_checksum></literal></para>
</entry>
- <entry>optional. If left out, autoyast lets yast decide what to do</entry>
+ <entry>Optional. If left out, &ay; lets &yast; decide what to do.</entry><remark>emap 2011-11-05: See my previous remark.</remark>
</row>
<row>
<entry>accept_verification_failed</entry>
- <entry><para>the installer will accept files where the verification of the signature failed. So the file was signed but the check failed.</para>
+ <entry><para>If set to "true", &ay; will accept signed files even when the verification of the signature failed.</para>
<para><literal><accept_verification_failed config:type="boolean">true</accept_verification_failed></literal></para>
</entry>
- <entry>optional. If left out, autoyast lets yast decide what to do</entry>
+ <entry>Optional. If left out, &ay; lets &yast; decide what to do.</entry><remark>emap 2011-11-05: Same here. Unless I'm just not getting it, please fix all other occurrences below.</remark>
</row>
<row>
<entry>accept_unknown_gpg_key</entry>
- <entry><para>the installer will accept new gpg keys on the installation source that are used to sign the content file for example</para>
+ <entry><para>If set to "true", &ay; will accept new gpg keys on the installation source, for example the key used to sign the content file.</para>
<para><literal><accept_unknown_gpg_key config:type="boolean">true</accept_unknown_gpg_key></literal></para>
</entry>
- <entry>optional. If left out, autoyast lets yast decide what to do</entry>
+ <entry>Optional. If left out, &ay; lets &yast; decide what to do.</entry>
</row>
<row>
<entry>accept_non_trusted_gpg_key</entry>
- <entry><para>This basically means, we know the key, but it is not trusted</para>
+ <entry><para>This basically means, we know the key, but it is not trusted.</para>
<para><literal><accept_non_trusted_gpg_key config:type="boolean">true</accept_non_trusted_gpg_key></literal></para>
</entry>
- <entry>optional. If left out, autoyast lets yast decide what to do</entry>
+ <entry>Optional. If left out, &ay; lets &yast; decide what to do.</entry>
</row>
<row>
<entry>import_gpg_key</entry>
- <entry><para>the installer will accept and import new gpg keys on the installation source in it's database.</para>
+ <entry><para>If set to "true", &ay; will accept and import new gpg keys on the installation source in its database.</para>
<para><literal><import_gpg_key config:type="boolean">true</import_gpg_key></literal></para>
</entry>
- <entry>optional. If left out, autoyast lets yast decide what to do</entry>
+ <entry>Optional. If left out, &ay; lets &yast; decide what to do.</entry>
</row>
</tbody>
</tgroup>
</informaltable>
<para>
- Since openSUSE 10.3 it's possible to configure the signature handling for each add-on individually. The following elements must be between the
- <signature-handling> section of the individual add-on.
+ Since openSUSE 10.3, it is possible to configure the signature handling for each add-on product individually. The following elements must be between the
+ <signature-handling> section of the individual add-on product.
</para>
<informaltable frame='top'>
@@ -253,28 +248,28 @@
<tbody>
<row>
<entry>accept_unsigned_file</entry>
- <entry><para>the installer will accept unsigned files like the content file for this add-on product</para>
+ <entry><para>If set to "true", &ay; will accept unsigned files like the content file for this add-on product.</para>
<para><literal><accept_unsigned_file config:type="boolean">true</accept_unsigned_file></literal></para>
</entry>
- <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry>
+ <entry>Optional. If left out, the global signature-handing in the <general> section is used.</entry>
</row>
<row>
<entry>accept_file_without_checksum</entry>
- <entry><para>the installer will accept files without a checksum in the content file for this add-on</para>
+ <entry><para>If set to "true", &ay; will accept files without a checksum in the content file for this add-on.</para>
<para><literal><accept_file_without_checksum config:type="boolean">true</accept_file_without_checksum></literal></para>
</entry>
- <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry>
+ <entry>Optional. If left out, the global signature-handing in the <general> section is used.</entry>
</row>
<row>
<entry>accept_verification_failed</entry>
- <entry><para>the installer will accept files where the verification of the signature failed. So the file was signed but the check failed.</para>
+ <entry><para>If set to "true", &ay; will accept signed files even when the verification of the signature fails.</para>
<para><literal><accept_verification_failed config:type="boolean">true</accept_verification_failed></literal></para>
</entry>
- <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry>
+ <entry>Optional. If left out, the global signature-handing in the <general> section is used.</entry>
</row>
<row>
<entry>accept_unknown_gpg_key</entry>
- <entry><para>the installer will accept new gpg keys on the installation source that are used to sign the content file for example</para>
+ <entry><para>If set to "true", &ay; will accept new gpg keys on the installation source, for example the key used to sign the content file.</para>
<screen>
<accept_unknown_gpg_key>
<all config:type="boolean">false</all>
@@ -284,11 +279,11 @@
</accept_unknown_gpg_key>
</screen>
</entry>
- <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry>
+ <entry>Optional. If left out, the global signature-handing in the <general> section is used.</entry>
</row>
<row>
<entry>accept_non_trusted_gpg_key</entry>
- <entry><para>This basically means, we know the key, but it is not trusted</para>
+ <entry><para>This basically means, we know the key, but it is not trusted.</para>
<screen>
<accept_non_trusted_gpg_key>
<all config:type="boolean">false</all>
@@ -302,7 +297,7 @@
</row>
<row>
<entry>import_gpg_key</entry>
- <entry><para>the installer will accept and import new gpg keys on the installation source in it's database.</para>
+ <entry><para>If set to "true", &ay; will accept and import new gpg keys on the installation source into its database.</para>
<screen>
<import_gpg_key>
<all config:type="boolean">false</all>
@@ -312,7 +307,7 @@
</import_gpg_key>
</screen>
</entry>
- <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry>
+ <entry>Optional. If left out, the global signature-handing in the <general> section is used.</entry>
</row>
</tbody>
</tgroup>
@@ -320,7 +315,7 @@
</section>
<section>
- <title>Kernel packages</title>
+ <title>Kernel Packages</title>
<para>
Kernel packages are not part of any selection. The required kernel
is determined during installation. If the kernel package is added to any selection
@@ -328,13 +323,12 @@
</para>
<para>
To force the installation of a specific kernel, use the
- <emphasis>kernel</emphasis> property. The following is an example
- forcing the installation of the default kernel. In this example this
- kernel will be installed in any case, even if an SMP or other kernel
- is required</para>
+ <emphasis>kernel</emphasis> property. The following is an example of
+ forcing the installation of the default kernel. This kernel will be
+ installed even if an SMP or other kernel is required.</para>
<example>
<title>
- Package selection in control file
+ Package Selection in Control File<remark>emap 2011-11-05: Should this read: Kernel Selection in Control File?</remark>
</title>
<screen>
