Archive for September 2011
Creating upgradable rpm packages (-Uvh)
Posted on Sat, Sep 24, 2011 at 11:23 by Hubertus A. Haniel
When creating rpm packages one should bear in mind that during a package upgrade the pre and post install and uninstall scripts are also run and it can happen that modifications are executed that you may not want to execute during the upgrade eg removal of files in a postuninstall which will actually still be needed after the upgrade. I belive the postuninstall is actually being run after the package has been upgraded. To get around this one should use the following framework:
%pre
if [ "$1" = "1" ]; then
Do stuff that should happen during initial installation.
elif [ "$1" = "2" ]; then
Do stuff that should happen during upgrade.
fi
%post
if [ "$1" = "1" ]; then
Do stuff that should happen during initial installation.
elif [ "$1" = "2" ]; then
Do stuff that should happen during upgrade.
fi
%preun
if [ "$1" = "0" ]; then
Do stuff that should happen during removal of the package.
elif [ "$1" = "1" ]; then
Do stuff that should happen during upgrade.
fi
%postun
if [ "$1" = "0" ]; then
Do stuff that should happen during removal of the package.
elif [ "$1" = "1" ]; then
Do stuff that should happen during upgrade.
fi
Edited on: Tue, Mar 13, 2012 11:34
Posted in HowTo (RSS), Packaging (RPM) (RSS), System - Linux (RSS)
Verification-time script in rpm
Posted on Fri, Sep 23, 2011 at 18:14 by Hubertus A. Haniel
This could be useful - found this in the rpm documentation while I was searching for something else so I thought I put it here for later :)
The %verifyscript executes whenever the installed package is verified by RPM's verification command. The contents of this script is entirely up to the package builder, but in general the script should do whatever is necessary to verify the package's proper installation. Since RPM automatically verifies the existence of a package's files, along with other file attributes, the %verifyscript should concentrate on different aspects of the package's installation. For example, the script may ensure that certain configuration files contain the proper information for the package being verified:
for n in ash bsh; do
echo -n "Looking for $n in /etc/shells... "
if ! grep "^/bin/${n}\$" /etc/shells > /dev/null; then
echo "missing"
echo "${n} missing from /etc/shells" >&2
else
echo "found"
fi
done
In this script, the config file /etc/shells, is checked to ensure that it has entries for the shells provided by this package.
It is worth noting that the script sends informational and error messages to stdout, and error messages only to stderr. Normally RPM will only display error output from a verification script; the output sent to stdout is only displayed when the verification is run in verbose mode.
Edited on: Sat, Sep 24, 2011 18:39Posted in HowTo (RSS), Packaging (RPM) (RSS), System - Linux (RSS)
nosrc.rpm files
Posted on Thu, Sep 22, 2011 at 17:43 by Hubertus A. Haniel
It is rather often that we have to package up binaries in rpm format for which there are no sources available and the vendor does not supply them in rpm format. - For this the best way to do this is using the NoSource tag in the SPEC file,
When building the RPM the result is apart from the package you want is also that rather then having a src.rpm as the source rpm you end up with a nosrc.rpm file. This nosrc.rpm file will only contain the spec file and not the sources that have been specified. This can be quite handy to grab files out of a running system.
So in the header of the SPEC file you would have something like
Source0: some.binary.%{_target_cpu}
NoSource: 0
As this binary will be architecture specific in most cases you should also ensure that you set the ExclusiveArch tag to ensure that the package does not get rebuild with the wrong architecture as a target. In this case I have two architecture specific binaries and with the above %{_target_cpu} the correct one gets selected when I specify the --target parameter on rpmbuild. My ExclusiveArch tag is set as below:
ExclusiveArch: i586 x86_64
An example of a package where I have used this concept can be found here.
Edited on: Sat, Sep 24, 2011 18:38Posted in HowTo (RSS), Packaging (RPM) (RSS), System - Linux (RSS)
OpenSuSE filesystem snapshots on btrfs
Posted on Mon, Sep 19, 2011 at 17:16 by Hubertus A. Haniel
Only recently did I find out about a new cool feature on the OpenSuSE Factory builds called snapper. It has been in the works for quite a while and was actually announced back in April here but it is only recently that I have tried these tools out while familiarising myself with btrfs
Snapper is reasonably easy to configure and there are quite a few guides on the OpenSuSE website. Once it is all configured it creates snapshots of your system on regular intervals via cron and also everytime you make modifications to your system using zypper and YaST but it requires that your root filesystem is btrfs. - The only drawback currently is that you can not boot of btrfs so you can not create snapshots of the /boot filesystem and therfore you would not be able to roll back kernel updates unless you replicate the contents of /boot into your btrfs filesystem before kernel upgrades.
A detailed guide on how to get snapper going which I followed is here but it should be noted that the subvolume for snapshots should be created as /.snapshots rather then /snapshots otherwise things will just not work.
So on your btrfs root filesystem or any filesystem that you want to snapshot you create a subvolume called .snapshots like so:
btrfs subvolume create /.snapshots
Then you create your configuration in /etc/snapper/configs/root for your root filesystem. - I got the example out of /etc/snapper/config-templates/default
Then you add "root" to SNAPPER_CONFIGS in /etc/sysconfig/snapper
Now everything should be ready to work and you can try to create an initial snapshot with the following command:
snapper create --description "initial"Edited on: Sat, Sep 24, 2011 17:41
Posted in HowTo (RSS), System - Linux (RSS)
