You can install software on the new system using a pre-defined package base selection, i.e. Minimal, Minimal+X11, default etc. in addition to several Add-on selections. Check the first CD for available selections in suse/setup/descr/selections, depending on the product you are installing, some "well-known" selections might not be available.

In the control file, packages and package selections are described as the following:

  <software>
    
    <addons  config:type="list">
      <addon>Kde</addon>
    </addons>
    <base>Minimal</base>
    <packages  config:type="list">
      <package>apache</package>
      <package>sendmail</package>
    </packages>
  </software>

	  

You can install one base selection and additionally one or multiple add-on selections.

When installing from a CD-ROM, needed packages from other CD-ROMs are installed after the initial boot of the system in the second installation phase. If you are installing packages from multiple CD-ROMs, then auto-installation has to be interrupted for switching the CD-ROMs. In the case of NFS installation, all packages are installed at first stage of the installation only if the NFS repository is configured as a single medium.

It is often required, that a package should be installed in the second phase, especially custom packages which may contain scripts for configuring the system. This can be done using the post-packages resource.

SLES10 no longer supports selections but uses patterns 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 addon entries and the base entry. Patterns are configured like this:

  <software>
    <patterns config:type="list">
        <pattern>directory_server</pattern>
    </patterns>
    <packages  config:type="list">
      <package>apache</package>
      <package>sendmail</package>
    </packages>
  </software>

	  

As you can see, the packages section is still the same like on a SLES9. Just the addon and base is gone.

In addition to the pre-defined selections, you can create custom selections by providing a selection file in the selection directory. (suse/setup/descr) The selection files have a special format and any additional selection file must conform to this format, otherwise YaST2 will not be able to read it.

As an example for the selection file, take a look at the files available in the directory /suse/setup/descr/ on the CD-ROMs.

After creating a selection file, you can add it to the configuration as described earlier in this section. The selection name, for example My.sel has to be added to the index files selections and directory.yast to make it visible to the installer.

The file My.sel should have the following format:

  # SuSE-Linux-Package-Selection 3.0 -- (c) 2004 SuSE Linux AG
# generated on Thu Apr 15 19:49:04 UTC 2004

=Ver: 3.0

=Sel:  LSB

=Sum: LSB Runtime Environment
=Sum.de: LSB-Laufzeitumgebung


=Cat: addon

=Vis: true

=Ord: 108

+Ins:
XFree86-Mesa
XFree86-libs
expect
fontconfig
freetype2
gettext
glibc-i18ndata
libgcj
lsb
make
makedev
patch
pax
rsync
-Ins:


         

To use the above selection, the following should be added in the control file:

  

    ...
  <software>
      <base>My</base>
  </software>
  ...

          

In addition to the packages available for installation on the CD-ROMs, you can add external packages including customized kernels. Customized kernel packages must be compatible to the SuSE packages and must install the kernel files to the same locations.

Unlike earlier versions, to install custom and external packages there is no need for a special resource in the control file. Instead you need to re-create the package database and update it with any new packages or new package versions in the source repository.

A script is provided for this task which will query packages available in the repository and create the required package database.

Creating a new package database is only needed if new RPMs (i.e. update RPMs) were added. To re-create the database, use the /usr/bin/create_package_descr command. For example, use this command line to create the package database. (When creating the database, all languages will be reset to English).

	cd /usr/local/CDs/LATEST/suse
	create_package_descr  -x PATH_TO_EXTRA_PROV -d /usr/local/CDs/LATEST/suse 
      

	Change starting from SUSE Linux 9.1/SLES 9
	To provide extra dependencies which can not be extracted from the rpm files, an extra file with missing dependencies is available in the directory suse/setup/descr. The file EXTRA_PROV can be used when recreating the package database using the -x option.

In the above example, the directory /usr/local/CDs/LATEST/suse contains the architecture dependent and independent packages, i.e. noarch and i586. This might look different on other architectures.

The advantage of this method is that you can keep an up-to-date repository with fixed and updated package (i.e. from SuSE FTP server). Additionally this method makes the creation of custom CD-ROMs easier.

Change starting from SUSE Linux 10.1/SLES 10

With SLES10/SL10.1, the concept of adding own RPMs to an installation source has changed. The yast/order and yast/instorder is no longer supported. Neither by AutoYaST nor by YaST. To add own RPMs to an installation source (that includes add-on products like the SDK) you have to add a file add_on_products to the CD1 of the main product. media_url [path_on_media [product_1 [product_2 [....]]] media_url is URL of the media itself path_on_media is path of the catalog on the media. If not present, / (root) is assumed product_1 and following are the names for products, which should be marked for installation. If no product is mentioned, all products found on the media are selected for installation. For example: http://192.168.66.6/SLES10/sdk/CD1 http://192.168.66.6/SLES10/CD1/updates Besides that add_on_products file, you can use the autoyast profile to specify add-on products. For example: <add-on> <add_on_products config:type="list"> <listentry> <media_url>http://192.168.66.6/SLES10/CD1/updates</media_url> <product>SuSE-Linux-Updates</product> <product_dir>/</product_dir> </listentry> </add_on_products> </add-on> With that entry in the autoyast profile, the add_on_products file is not necessary. YaST checks the signatures of files on the installation source now. If a content file is not signed, during a manual installation YaST asks the user what to do. During an autoinstallation, the installation source gets rejected silently.

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 general section.

The following elements must be between the <general><signature-handling> ... </signature-handling></general> tags.

<accept_unsigned_file config:type="boolean">true</accept_unsigned_file>

<accept_file_without_checksum config:type="boolean">true</accept_file_without_checksum>

<accept_verification_failed config:type="boolean">true</accept_verification_failed>

<accept_unknown_gpg_key config:type="boolean">true</accept_unknown_gpg_key>

<accept_non_trusted_gpg_key config:type="boolean">true</accept_non_trusted_gpg_key>

<import_gpg_key config:type="boolean">true</import_gpg_key>

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.

<accept_unsigned_file config:type="boolean">true</accept_unsigned_file>

<accept_file_without_checksum config:type="boolean">true</accept_file_without_checksum>

<accept_verification_failed config:type="boolean">true</accept_verification_failed>

           <accept_unknown_gpg_key>
            <all config:type="boolean">false</all>
             <keys config:type="list">
               <keyid>3B3011B76B9D6523</keyid>
             </keys>
           </accept_unknown_gpg_key>
                  

           <accept_non_trusted_gpg_key>
            <all config:type="boolean">false</all>
             <keys config:type="list">
               <keyid>3B3011B76B9D6523</keyid>
             </keys>
           </accept_non_trusted_gpg_key>

           <import_gpg_key>
            <all config:type="boolean">false</all>
             <keys config:type="list">
               <keyid>3B3011B76B9D6523</keyid>
             </keys>
           </import_gpg_key>
             

Kernel packages are not part of any selection. The required kernel is determined during installation. If the kernel package is added to any selection or to the individual package selection, installation will mostly fail due to conflicts.

To force the installation of a specific kernel, use the kernel 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

  <software>        
    <addons  config:type="list">
      <addon>Kde</addon>
    </addons>
    <base>Minimal</base>
    <kernel>kernel-default</kernel>
    <packages  config:type="list">
      <package>apache2</package>
    </packages>
  </software>

	  

Some packages are selected automatically either because of a dependency or because it available in a selection.

Removing such packages might break the system consistency and it is not recommended to remove basic packages unless a replacement which provides same services is provided. Best example for this case are MTA packages. By default, postfix will be selected and installed. If you wish however to use another MTA like sendmail, then postfix can be removed from the list of selected package using a list in the software resource. The following example shows how this can be done:

  <software>
    <addons  config:type="list">
      <addon>Kde</addon>
    </addons>
    <base>Minimal</base>
    <packages  config:type="list">
      <package>sendmail</package>
    </packages>
    <remove-packages  config:type="list">
      <package>postfix</package>
    </remove-packages>
  </software>



	  

if you want to install packages after the reboot during stage 2, instead of during the normal installation process in stage 1, you can use the post-packages element for that:

<software>
  <post-packages config:type="list">
    <package>yast2-cim</package>
  </post-packages>
</software>