Software Management/Code11/Scripts and Messages

From openSUSE

Code11 Update Scripts and Messages

Scripts

Purpose

Maintenance updates sometimes need additional steps to be executed outside the packages %pre and %post scripts.

Examples are any manipulations of the rpm database (which is locked during a package transaction), like running "rpm --rebuilddb"

Such scripts are a 'least resort' for any update steps which must run outside of a rpm process. It is an exceptional case and should be treated as such. For Code10, only a service pack migration required such a script.

Implementation

Update scripts are per-package.

An update script must be packaged in an RPM package. This allows access to the script with 3rd party tools which usually deal only with RPMs.

[Its important to keep 'rpm only' (resp. 3rd party tools) in mind. Use of our tools (zypper, YaST) for patch&update should make things smooth and easy - but not preclude other tools, which in turn might need manual steps.]

The script is run by bash (/bin/sh) with 'root' rights.

An RPM can package at most one such script. If multiple scripts must be run, create one 'master' script calling other scripts in the right order.

libzypp ensures execution of the update script immediately after the corresponding RPM was successfully updated. Except for updates flagged as 'restart_suggested' which trigger a restart of the update stack. In this case the script is run when the updated stack is restarted.

If the script depends on other package updates, proper 'PreRequires' for the package containing the script must be set.

There is no guarantee any shell commands (like sed, awk, etc.) or scripting languages (Perl, Python, etc.) are installed. The package containing the script must express such requirements explicitly (just like any %pre or %post script requirements).

Update scripts are installed below '/var/adm/update-scripts'.

The name of the script must be prefixed by "<name>-<version>-<release>-" of the package containing the script. This ensures scripts are non-ambiguous. See [I.4 Packaging] below on packaging tips.

Limitations

Scripts must be idempotent - running them multiple times must not have side effects.

Packaging

Update scripts must be packaged within an RPM. The script should have a proper name (remember the 'rpm only' case above) and listed as a 'Source' in the .spec file

 Source1:        testing-one-two.sh
 

Installation should copy the file into /var/adm/update-scripts and prefix it with "<name>-<version>-<release>-" of the package:

 %intstall
 ...
 cp %_sourcedir/testing-one-two.sh $RPM_BUILD_ROOT/var/adm/update-scripts/%{name}-%{version}-%{release}-testing-one-two.sh
 

Last step in inclusion of the script in the %files section of the .spec file:

 %files
 ...
 /var/adm/update-scripts/%{name}-%{version}.%{release}-testing-one-two.sh

[These steps should be wrapped inside RPM macros. One for the %install and one for the %files section. Negotiations with autobuild are pending ;-)]

Internals

The location where libzypp looks for update scripts is configurable via the 'update.scriptsdir' setting of /etc/zypp/zypp.conf This might be useful for debugging.

Messages

Purpose

Messages provide notifications before (pre-message) or after (post-message) a package install (resp. update)

Pre-messages are bound to updates and implemented through updateinfo.xml (TODO: link to documentation)

Post-message follow the concept outlined above for scripts.

Implementation

Messages are per-package.

A message must be packaged in an RPM package. This allows access to the message with 3rd party tools which usually deal only with RPMs.

[Its important to keep 'rpm only' (resp. 3rd party tools) in mind. Use of our tools (zypper, YaST) for patch&update should make things smooth and easy - but not preclude other tools, which in turn might need manual steps.]

An RPM can package at most one such message. If multiple messages must be displayed, distribute them across multiple packages

Messages are installed below '/var/adm/update-messages'.

The name of the message must be prefixed by "<name>-<version>-<release>-" of the package containing the message. This ensures messages are non-ambiguous. See [I.4 Packaging] below on packaging tips.

Limitations

(TODO) UTF-8 encoded ?

Localization ?

Packaging

Messages must be packaged within an RPM. The message should have a proper name (remember the 'rpm only' case above) and listed as a 'Source' in the .spec file

 Source1:        testing-one-two.txt
 

Installation should copy the file into /var/adm/update-messages and prefix it with "<name>-<version>-<release>-" of the package:

 %intstall
 ...
 cp %_sourcedir/testing-one-two.txt $RPM_BUILD_ROOT/var/adm/update-messages/%{name}-%{version}-%{release}-testing-one-two.txt
 

Last step in inclusion of the message in the %files section of the .spec file:

 %files
 ...
 /var/adm/update-message/%{name}-%{version}.%{release}-testing-one-two.txt

[These steps should be wrapped inside RPM macros. One for the %install and one for the %files section. Negotiations with autobuild are pending ;-)]

Internals

The location where libzypp looks for messages is configurable via the 'update.messagesdir' setting of /etc/zypp/zypp.conf This might be useful for debugging.