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>