SDB:Creating YaST installation sources
Generating YaST installation sources
There are three types of installation sources for YaST: plain cache, yum, and "real" YaST sources.
Plain cache sources
A plain cache source is a directory containing RPM files. For YaST to recognize a directory as a plain cache source, you must create a file (IS_PLAINcache) that contains the RPM header information of the available RPM packages. YaST needs the package data (name, version, dependencies, etc.) from the .rpm file in order to avoid reading the file over and over again. For large packages, this would result in extremely long transfer times, even if you do not want to install the package. Therefore, the needed package data is extracted from the packages and stored in a file.
This file can be created with the genIS_PLAINcache utility, which is included in the package yast2-packagemanager.
Advantages
- Easy to generate
Disadvantages
- Source RPMs (src.rpm) are not supported
- Multiple architectures (i586, i686, noarch, ppc, etc.) are not supported
- No description of the installation source in YaST
- genIS_PLAINcache is a binary (not a script) that only runs on SUSE systems
Example
You have a directory with a number of binary RPM files on your server and want to make it available as a YaST installation source via HTTP or FTP.
/srv/www/htdocs/suse/RPMS/
`- software1-1.0-1.i686.rpm
`- software2-1.0-1.i686.rpm
`- software3-1.0-1.i686.rpm
`- test/
`- test1-0.99-1.i686.rpm
`- test2-0.99-1.i686.rpm
`- test3-0.99-1.i686.rpm
Run the following commands in order to generate a plain cache source:
cd /srv/www/htdocs/suse/RPMS/ genIS_PLAINcache -f -r . gzip genIS_PLAINcache
Subsequently, you can add the directory as installation source in YaST -> Change Source of Installation. Note the restrictions mentioned above.
repomd/rpm md/YUM sources
A repomd source (also called rpm md or yum source) is a directory containing RPM files or subdirectories containing RPM files. For YaST to recognize a directory as a repomd source, you must create the repodata directory that contains the RPM header information of the available RPM packages (for the same reasons as in plain cache sources).
This file can be created with the createrepo utility, which is included in the package createrepo.
Advantages
- Easy to generate
- Multiple architectures are supported
Disadvantages
- Source RPMs (src.rpm) are not supported
Example
You have a directory with a number of RPM files on your server and want to make it available as a YUM installation source.
/srv/www/htdocs/suse/RPMS/
`- i686/
`- software1-1.0-1.i686.rpm
`- software2-1.0-1.i686.rpm
`- software3-1.0-1.i686.rpm
`- i586/
`- software1-1.0-1.i586.rpm
`- software2-1.0-1.i586.rpm
`- software3-1.0-1.i586.rpm
`- test/
`- test1-0.99-1.i686.rpm
`- test2-0.99-1.i686.rpm
`- test3-0.99-1.i686.rpm
Run the following commands in order to generate a YUM installation source:
# createrepo /srv/www/htdocs/suse/RPMS
Subsequently, you can add the directory as an installation source in YaST -> Change Source of Installation.
YaST sources
A "real" YaST source (also called susetags source) consists of several files and directories that describe the installation source and its content: binary RPM files for various architectures and the respective source RPM files. Some of the descriptive files can be generated with the create_package_descr script, which is in the package autoyast2-utils.
Advantages
- Source RPMs are supported
- Multiple architectures are supported
- Smaller than XML files
- Repositories spanning multiple media (e.g. CDs) are supported
- The description of the installation source is displayed in YaST
- Multilingual descriptions are supported
- Exact package sizes (per directory) are supported
- Virtual provides (extra provides) can be used
Disadvantages
- Not so easy to generate
Example
The description of the installation source is split in several files:
media.1/
`- media
content
content.asc # optional
content.key # optional
directory.yast
setup/descr/
`- packages
`- packages.DU
`- packages.en
- media.1/media
The file media.1/media contains a medium description consisting of the following components:
Content:
<Author> <Date of creation (YYYYMMDDhhmmss)> <Number of media>
Example:
Packman 20040127150052 1
Tip: The date string can be generated with the date utility:
date +%Y%m%d%H%M%S
The date field can be anything, its only use is to identify multiple media belonging to the same set. Using the date just makes it easier to tell the exact version during beta/rc phase of product development.
- content
The content file contains a medium content description consisting of the following components:
Key Content PRODUCT Product name VERSION Product version VENDOR Product vendor LABEL Source designation to be used in YaST ARCH.<base> Supported architectures for the base architecture DEFAULTBASE Default base architecture in case the base architecture cannot be determined by YaST DESCRDIR The directory containing the package descriptions DATADIR The directory containing the packages
Example:
PRODUCT Packman VERSION 10.0-0 LABEL Packman (SUSE LINUX 10.0) VENDOR Packman Packager Team ARCH.i686 i686 i586 i486 i386 noarch ARCH.i586 i586 i486 i386 noarch DEFAULTBASE i586 DESCRDIR setup/descr DATADIR RPMS
As of SUSE Linux 10.1 the installation sources are secured by cryptographically signing the content file and using SHA1 checksums. A detached signature (i.e. a signature that is placed in a separate file) is used. For your own installation sources this is optional, but highly recommended. See the page on secure installation sources for details.
content.asc
contains the signature, and the public key of the GPG key pair that was used to sign the file can be placed next to the content and content.asc files in a file called
content.key
to make it easier for the user to import the key into the RPM keyring.
In the content file two additional optional tags are allowed, META and KEY. If they are present, they have to be used as such:
- For every file in the directory DESCRDIR (e.g. setup/descr) there must be a META entry.
- For every GPG key that is used to sign RPM packages and should be added to the RPM keyring there must be a KEY entry. The keys themselves have to be placed in the same directory as the content file.
Example:
META SHA1 b5e293f8df00bfe45d3ed4521af2d9befe48656f Basis-Devel-10.1-42.noarch.sel META SHA1 4bbb4a037421bbb5b4d9df7ecaa0e48e7f0edf67 packages KEY SHA1 a108c6aab19fe604fa98ef299cdce6e6ba275f09 gpg-pubkey-0dfb3188-41ed929b.asc
Both tags have three attributes. The first indicates the checksum type that is used (at the moment only SHA1 is allowed), the second is the checksum, and the third is the file name of the metadata file or key.
- directory.yast
YaST uses the file if the installation source is addressed by means of a protocol that does not support directory listing (such as HTTP). This file can easily be generated with the ls utility:
ls -A1 > directory.yast
Example:
RPMS content directory.yast media.1 setup
- setup/descr/*
These files can be generated with the create_package_descr script. They contain the dependencies, the size, and the package descriptions of all packages in the installation source.
Example:
Your FTP server has a directory containing binary and source RPM packages for SUSE Linux. Most binary RPM packages are available for two architectures (i586/i686). Moreover, some scripts are packed in architecture-independent RPM packages (noarch). You want to offer this directory as a YaST installation source for SUSE Linux 10.0.
/srv/ftp/pub/linux/suse/10.0/RPMS/
`- i586/
| `- software1-1.0-1.i586.rpm
| `- software2-1.0-1.i586.rpm
`- i686/
| `- software1-1.0-1.i686.rpm
| `- software2-1.0-1.i686.rpm
`- noarch/
| `- script1-1.0-1.noarch.rpm
| `- script2-1.0-1.noarch.rpm
`- src/
`- software1-1.0-1.src.rpm
`- software2-1.0-1.src.rpm
`- script1-1.0-1.src.rpm
`- script2-1.0-1.src.rpm
To generate a "real" YaST source from this directory, execute the following commands:
cd /srv/ftp/pub/linux/suse/10.0/ mkdir media.1 $EDITOR media.1/media $EDITOR content ls -A1 > directory.yast create_package_descr -d RPMS/
The create_package_descr script is located in package inst-source-utils or can be downloaded from sf.net. Ungzip the package, save it in your path and do a chmod 755 on it.
The script will be extended to optionally also generate cryptographic signatures and checksums, so it will be easy to create secure repositories on your own.
Further documentation
Further documentation regarding the YaST installation sources is available in the package yast2-packagemanager-devel.
See also
YaST module called Add-On Creator offers a GUI for creating of Add-On products, which can be used as an installation sources.