DESCRIPTION

The RPM2 module provides an object-oriented interface to querying both the installed RPM database as well as files on the filesystem.

CLASS METHODS

Pretty much all use of the class starts here. There are three main entrypoints into the package -- either through the database of installed rpms (aka the rpmdb), through a file on the filesystem (such as kernel-2.4.9-31.src.rpm or kernel-2.4.9-31.i386.rpm, or via an rpm transaction.

You can have multiple RPM databases open at once, as well as running multiple queries on each. That being said if you expect to run a transaction to install or erase some rpms, you will need to cause any RPM2::DB and RPM2::PackageIterator objects to go out of scope. For instance:

Would end up in a dead lock waiting for $db, and $i (the RPM2::DB and RPM2::PackageIterator) objects to releaase their read lock on the database. The correct way of handling this then would be to do the following before running the transaction:

$db = undef;
$i = undef;

That is to explicitly cause the RPM2::DB and RPM2::PackageIterator objects to go out of scope.

open_rpm_db(-path => "/path/to/db")

As it sounds, it opens the RPM database, and returns it as an object. The path to the database (i.e. -path) is optional.

open_package("foo-1.1-14.noarch.rpm")

Opens a specific package (RPM or SRPM). Returns a Header object.

create_transaction(RPM2->vsf_default)

Creates an RPM2::Transaction. This can be used to install and remove packages. It, also, exposes the dependency ordering functionality. It takes as an optional argument verify signature flags. The following flags are available:

RPM2->vsf_default

You don't ever have to specify this, but you could if you wanted to do so. This will check headers, not require a files payload, and support all the various hash and signature formats that rpm supports.

RPM2->vsf_nohdrchk

Don't check the header.

RPM2->vsf_needpayload

Require that a files payload be part of the RPM (Chip is this right?).

RPM2->vsf_nosha1header

RPM2->vsf_nomd5header

RPM2->vsf_nodsaheader

RPM2->vsf_norsaheader

RPM2->vsf_nosha1

RPM2->vsf_nomd5

RPM2->vsf_nodsa

RPM2->vsf_norsa

RPM DB object methods

find_all_iter()

Returns an iterator object that iterates over the entire database.

find_all()

Returns an list of all of the results of the find_all_iter() method.

find_by_file_iter($filename)

Returns an iterator that returns all packages that contain a given file.

find_by_file($filename)

Ditto, except it just returns the list

find_by_name_iter($package_name)

You get the idea. This one is for iterating by package name.

find_by_name($package_name)

Ditto, except it returns a list.

find_by_provides_iter($provides_string)

This one iterates over provides.

find_by_provides($provides_string)

Ditto, except it returns a list.

find_by_requires_iter($requires_string)

This one iterates over requires.

find_by_requires($requires_string)

Ditto, except it returns a list.

RPM Database Iterator Methods

Once you have a a database iterator, then you simply need to step through all the different package headers in the result set via the iterator.

next()

Return the next package header in the result set.

expand_iter()

Return the list of all the package headers in the result set of the iterator.

RPM Header object methods

In addition to the following methods, all tags have simple accessors; $hdr->epoch() is equivalent to $hdr->tag('epoch').

The <=> and cmp operators can be used to compare versions of two packages.

$hdr->tag($tagname)

Returns the value of the tag $tagname.

$hdr->tagformat($format)

TODO.

$hdr->is_source_package()

Returns a true value if the package is a source package, false otherwise.

$hdr->filename()

Returns the filename of the package.

$hdr->offset()

Returns the rpm database offset for the package.

$hdr->as_nvre()

Returns a string formatted like:

epoch:name-version-release

If epoch is undefined for this package, it and the leading colon are omitted.

$hdr->files()

TODO.

$hdr->changelog()

Returns a list of hash refs containing the change log data of the package. The hash keys represent individual change log entries, and their keys are: time (the time of the changelog entry), name (the "name", ie. often the email address of the author of the entry), and text (the text of the entry).

Transaction object methods

Transactions are what allow you to install, upgrade, and remove rpms. Transactions are created, have elements added to them (i.e. package headers) and are ran. When run the updates to the system and the rpm database are treated as on "transaction" which is assigned a transaction id. This can be queried in install packages as the INSTALLTID, and for repackaged packages they have the REMOVETID set.

add_install($pkg, $upgrade)

Adds a package to a transaction for installation. If you want this to be done as a package upgrade, then be sure to set the second optional parameter to 1. It will return 0 on failure and 1 on success. Note, this should be obvious, but the package header must come from an rpm file, not from the RPM database.

add_erase($pkg)

Adds a package to a transaction for erasure. The package header should come from the database (i.e. via an iterator) and not an rpm file.

element_count()

Returns the number of elements in a transaction (this is the sum of the install and erase elements.

close_db()

Closes the rpm database. This is needed for some ordering of transactions for non-install purposes.

check()

Verify that the dependencies for this transaction are met. Returns 0 on failure and 1 on success.

order()

Order the elements in dependency order.

elements()

Return a list of elements as they are presently ordered. Note, this returns the NEVR's not the package headers.

run()

Run the transaction. This will automatically check for dependency satisfaction, and order the transaction.

TODO

Make package installation and removal better (-;.

Signature validation.

HISTORY

0.01 Initial release.

0.68 RPM 4.6 Support.

0.69 RPM 4.9 Support.

AUTHORS

RPM2 was originally written by Chip Turner <cturner@pattern.net> and contributions were made by numerous authors. It is currently maintained by Lubomir Rintel <lkundrak@v3.sk>.