Changes in rpm operation that should interest both users and developers.
Rpm database upgrade/downgrade is done automatically during package installation, so there is need to do anything.
But, in case that upgrade/downgrade did not happen for some reason, here is the command to do it manually:
/usr/lib/rpm/bin/dbupgrade.sh
Remember to back up rpm database before running this script.
You can't just do rm -rf /var/lib/rpm/__db*
to fix problems anymore, also --rebuilddb is largely obsolete in rpm 5 and isn't likely to “fix” anything. Instead do:
cd /var/lib/rpm db5.2_recover -ev
The semantics of rpm query option -f (--file) has changed in rpm 5.x; rpm -q -f <file-with-path>
will not resolve all symlinks in queried file's path. So the query (assuming /usr/src/linux is a symlink to /usr/src/linux-A.B.C-R):
rpm -q -f /usr/src/linux/include/linux/fs.h
That returned kernel-headers-A.B.C-R.arch.rpm with old rpm, will return nothing with rpm 5.x. You have to do readlink -f
first, or change to symlinked directory and do relative path query.
You have to remove .poldek-cache directory if, after rpm/poldek ugrade, you see error similiar to the following:
Loading [pndir]th... Loading [pndir]th... 19616 packages read Loading [rpmdbcache]/var/lib/rpm... rpmdb: /var/lib/rpm/__db.005: Too many open files error: db_init:db3.c:1087: dbenv->open(24): Too many open files error: cannot open Packages(0) index: Too many open files(24) DB: Berkeley DB 5.2.36: (September 14, 2011) error: //var/lib/rpm: open rpm database failed Abort
If running rpm built with BDB 5.3 you may see errors like this:
db3.c:1443: dbcursor->pget(-30999): BDB0063 DB_BUFFER_SMALL: User memory too small for return value
It appears to be some type of a bug in the BerkleyDB 5.3.x. In an attempt to workaround the problem, when we encounter this situation we attempt to adjust the size of the mmap buffer until the call works, or we end up trying 10 times.
If DBI debugging is enabled, additional diagnostics are printed, otherwise a basic retry and success message is added to show that the failure was resolved.
# poldek -u filesystem Processing dependencies... filesystem-4.0-1.x86_64 obsoleted by filesystem-4.0-26.x86_64 filesystem-4.0-26.x86_64 marks FHS-2.3-35.x86_64 (cap //) error: FHS-2.3-35.x86_64: equal version installed, give up
To fix, upgrade poldek, and invoke poldek --clean-all
, as the stored poldek indexes are invalid.
After upgrading rpm on a vserver host you need to convert rpm databases of vservers with external package management (default). For this purpose a special option has been added to vrpm wrapper from util-vserver in PLD. Use the following command to convert rpm database for a single vserver:
vrpm <vserver> --convertdb
Below is a list of changes in build system that should interest PLD developers.
/var/tmp
is now used when TMPDIR environment variable is not set, the reason for this change is to avoid future problems if/when systemd forces it's way of /tmp
as tmpfs With old rpm 4.x several macro files were loaded in .spec files via #include directive:
%include /usr/lib/rpm/macros.perl
In rpm 5.x those macro files have been moved to /usr/lib/rpm/macros.d/
directory, and must be loaded using %{load:} directive. However the old statement still works, as it contains the same code to load the macros.
%{load:/usr/lib/rpm/macros.d/perl}
Regexp patterns for _noauto*
macros changed slightly, and '(' must be escaped now, for example:
%define _noautoreq 'perl\\(something::.*\\)'
rpm-build-tools v1.654 adds handy macros to have same syntax for rpm4/5 .specs:
BuildRequires: rpmbuild(macros) >= 1.654 %define _noautoreq_pear Excluded.php PEAR/Something.php %define _noautoreq_perl Apache::.*
Rpm 5 supports noarch subpackages, a feature that can save space on ftp server and mirrors and ease use of multiarch packages.
To use it within a package, add in the preamble of a subpackage that should be/is architecture independent:
# noarch subpackages only when building with rpm5 %if "%{_rpmversion}" >= "5" BuildArch: noarch %endif
in rpm-5.4.10-35
webapp register was broken due triggers misbehave. here's quick fix for lighttpd:
for a in /etc/webapps/*/lighttpd.conf; do a=${a#/etc/webapps/}; a=${a%/*}; webapp register lighttpd $a; done
This problem has been identified and fixed rpm package will be released soon.