Inst-source-utils

Jump to: navigation, search

Some information about inst-source-utils

The new package inst-source-utils will replace the current package autoyast-utils. The scripts in the obsolete package are moved to the new package and extended with new ones. The main target of both packages: Provide utilities supporting autoinstallation and creation of customized package sources.

More information about AutoYaST is available here.

The package inst-source-utils will be enhanced in the near future. If you have additional scripts for the above target, feel free to Enter a bug an attach your scripts.


Short description of the scripts

Tool/ Script Description
create_directory.yast Creates the file directory.yast in each subdirectory of the (optional) targetdir (pwd is used if targetdir is not given as argument).

YaST needs this file during Network installation to "see" the content of the directory if the server doesn't support directory listings.

create_update_source.sh creates an update tree on the installation source in parallel of the actual installation tree.

Usage example: Suppose the source resides in myInstallSource

   ./create_update_source.sh myInstallSource
   cp -a myPackage-2.3.44.5-6.i586.rpm myInstallSource/updates/suse/i586
   cd myInstallSource/updates/suse
   create_package_descr -x setup/descr/EXTRA_PROV
   cd setup/descr
   create_directory.yast .
   create_md5sums .
create_md5sums Creates MD5SUMS files in each subdirectory of the (optional) targetdir (pwd is used if targetdir is not given as argument).

These MD5SUMS files are not used during installation any more. But are usefull if you copy files from one installation source to another. There a simple md5sums -c MD5SUMS is enough to check for any transmission errors.

create_package_descr YaST uses a file named packages located in the directory /suse/setup/descr/ as "package database" during installation. This script

creates such a package database file (See packages Metadata description for more details.) and also corresponding language files named package._lang_ which contain the language specific translations for the packages. See packagesLang Metadata description for more details.

So if you change or add some packages in your installation source, you need to run this script afterwards - otherwise YaST will not recognise any changes in your installation source.

The script comes with a set of parameters:

[-d DATADIR1

[-d DATADIR2 ... ] ] (default cwd)

Path to the packages and other metadata on your installation source.
[-p PDB_DATA_DIR ] Path to the directory containing a dump of the (currently SUSE internal) package database.

This directory should contain a file named <packagename>.pl for each package in your repository. (See pdbdump Metadata for more details.)

[-x EXTRA_PROV_FILE ] The file EXTRA-PROV contains dependencies, the packagemanager can't resolve during installation.

For example: if a package requires /bin/bash - the package manager couldn't resolve this because he doesn't know that the package "bash" contains this file. With an entry like "bash: /bin/bash" in the EXTRA_PROV file, create_package_descr will add a line containing "/bin/bash" as "Provides" to the packages file. So YaST "knows" during installation that the package "bash" must be installed - even if the package "bash" doesn't provide "/bin/bash".

Keep in mind that YaST doesn't use the EXTRA_PROV file but the packages file. You can use the EXTRA_PROV file on the media as draft for your own file.

[-i IGNORE_DIR ]

[-I IGNORE_FILE ]

Sometimes it could be useful to ignore just some files or directories (like setup/descr) in your Datadir.
[-l LANG1

[-l LANG2 [... ] ]

create_package_descr will create a file named package._lang_ for each of this languages containing

the summary and the description in the specific language. These language specific parts must be in the pdbdump Metadata - otherwise english will be used.

[-o OUTPUT_DIR ] Where to put the resulting packages* files.
[-Z ] If a package has a license that has to be confirmed manually by the user before installation, this

option can be used. Remember to have a license tag (named "confirmlic_yast") entered in the pdbdump Metadata of the package for every language (english is used as fallback).

[-S ] Add package informations for source packages (*.src.rpm), too.
[-P ] Use DT:Rich (some simple HTML Tags like

) instead of plain ASCII text for the description.

These texts are marked with the ending "_yast" (description_yast) in the pdbdump Metadata.

[-L ] With this option create_package_descr searches only for regular files.
[-C ] This option will add a sha1sum entry in the packages file for each package. This should be the default for

installation sources since 10.1.

 EXAMPLE: ./create_package_descr suse -x /home/foo/CD-Creation/EXTRA_PROV -p -/home/foo/CD-Creation/pdb 
 -i meta -o suse/setup/descr -l english -l german -l czech -l french -l spanish -l hungarian
createpatch Creates a valid XML patchfile for a set of packages. This script needs the basedir to the repository and

the Patch name as argument. Note that this was used only up to SLES 10 , future products use "updateinfo" style patchinfos. All other options described below are optional.

[-i PATCH_ID] Patch id, needs to be unique in world, will be prefixed by "hostname -d" as default followed by the name of the

first package. Dots in "hostname -d" will be converted to "_"s.

[-n PATCH_NAME] Required parameter, terse patch name, like aaa_base
[-v PATCH_VERSION] default to "0" first non-existant if not given
[-s PATCH_SUMMARY] default to the package summary of the first RPM specified on the command line
[-d PATCH_DESCRTIPON] Long description, defaults to the package description of the first RPM specified on commandline
[-C CATEGORY] Category for the patch. Defaults to recommended. Possible values: security, recommended, optional
[-p RPM_BASENAME

[,rpm_basename...]

List of RPMs for this patch. You need at least one. More can be separated by commata. (Hint: check the dependency

of a package to get an overview about needed packages for a patch.

[-u] Run createrepo to update repository and take care of keeping the patch*xml files - use when augmenting existing repository

with new patches. So your clients only need one Update-Repository - and you can fill it up with newer patches every day.

[-S] Detached sign the repomd.xml file like SUSE does for official openSUSE update Repos.
[-I KEY_ID] Key-id to use for signing the repomd.xml file, if not given gpg will use the default signing key of the user

calling the script.

[-L LICENSE_FILE] Add an EULA to the patch, read from the file specified. This EULA will be displayed bevor a patch will be installed.

The user has to accept the EULA manually.

 Example: ./createpatch -n "Security Update for foo and bar" -s "This patch solves CVE-000-0000" -d "An attacker could easily 
 hack your computer using..." -C security -u -p foo,bar update/10.1/
create_repo_for_patch.sh Generates a YUM repository out of a patchfile and an external repository containing the needed RPMs.
[-p] Additional patch files (if not located in <target_directory>)
[-P] Prefix for patchfiles (default: patch-). You should use something like your comany name or something similar to avoid

problems for endusers. (They can install only one patchfile with the same name...)

[-S] Detached sign the repomd.xml file, if not given gpg will use the default signing key of the user

calling the script.

[-I KEY_ID] Key-id to use for signing the repomd.xml file, if not given gpg will try to use the default signing key
[-v] Be verbose.
 Example: ./create_repo_for_patch.sh -S  .

WARING: create_repo_for_patch.sh will delete all files except patch files in the <target directory> !

mk_listings Creates the files ARCHIVES.gz, INDEX.gz and ls-lR.gz. These files can be used to search for:
  • files in RPMs => ARCHIVES.gz
  • files on the media => INDEX.gz and ls-lR.gz

Tools like pin use these files - but you can also just zgrep <filename> INDEX.gz.