Lintian::Lab::Manifest(3) Lintian Lab manifest


use Lintian::Lab::Manifest;

my $plist = Lintian::Lab::Manifest->new ('binary');
# Read the file
# fetch the entry for lintian (if any)
my $entry = $plist->get('lintian', '2.5.2', 'all');
if ( $entry && exits $entry->{'version'} ) {
print "Lintian has version $entry->{'version'}\n";
# delete all lintian entries
# Write to file if changed
if ($plist->dirty) {


Instances of this class provide access to the packages list used by the lab as caches.

The data structure is basically a tree (using hashes). For binaries is looks (something) like:


The (order of the) fields used in the tree are listed in the @{BIN,SRC,CHG}_QUERY lists below. The fields may (and generally do) differ between package types.


Creates a new packages list for a certain type of packages. This type defines the format of the files.

The known types are:
 * binary
 * changes
 * source
 * udeb

If TYPE is GROUP, then GROUPING should be omitted.


Returns a truth value if the manifest has changed since it was last written.
Returns the type of packages that this manifest has information about. (one of binary, udeb, source or changes)
read_list (FILE)
Reads a manifest from FILE. Any records already in the manifest will be discarded before reading the contents.

On success, this will clear the ``dirty'' flag and on error it will croak.

write_list (FILE)
Writes the manifest to FILE.

On success, this will clear the ``dirty'' flag and on error it will croak.

On error, the contents of FILE are undefined.

visit_all (VISITOR[, KEY1, ..., KEYN])
Visits entries and passes them to VISITOR. If any keys are passed they are used to reduce the search. See get for a list of (common) keys.

The VISITOR is called as:


where ENTRY is the entry and KEYS are the keys to be used to look up this entry via get method. So for the lintian 2.5.2 binary the keys would be something like:
 ('lintian', '2.5.2', 'all')

get (KEYS...)
Fetches the entry for KEYS (if any). Returns "undef" if the entry is not known. If KEYS is exactly one item, it is assumed to be a Lintian::Processable and the correct keys are extracted from it.

Otherwise, the keys are (in general and in order):

except for source packages
set (ENTRY)
Inserts ENTRY into the manifest. This may replace an existing entry.

Note: The interesting fields from ENTRY are copied, so later changes to ENTRY will not affect the data in the manifest.

set_transient_marker (TRANSIENT, KEYS...)
Set or clear transient flag. Transient entries are not written to the disk (i.e. They will not appear in the file created/written by ``write_list (FILE)''). KEYS is passed as is passed to ``get (KEYS...)''.

By default all entries are persistent.

delete (KEYS...)
Removes the entry/entries found by KEYS (if any). KEYS must contain at least one item - if the list of keys cannot uniquely identify a single element, all ``matching'' elements will be removed. Examples:

 # Delete the gcc-4.6 entry at version 4.6.1-4 that is also architecture i386
 $manifest->delete ('gcc-4.6', '4.6.1-4', 'i386');
 # Delete all gcc-4.6 entries at version 4.6.1-4 regardless of their
 # architecture
 $manifest->delete ('gcc-4.6', '4.6.1-4');
 # Delete all gcc-4.6 entries regardless of version and architecture
 $manifest->delete ('gcc-4.6')

If KEYS is exactly one item, it is assumed to be a Lintian::Processable. If so, the proper keys will be extracted from that processable and (if present) that one element will be removed.

This will mark the list as dirty if an element was removed. If it returns a truth value, an element was removed - otherwise it will return 0.

See ``get (KEYS...)'' for the key names.

Returns a diff between this manifest and MANIFEST.

This instance is considered the ``original'' and MANIFEST is ``new'' version of the manifest. (See the olist and nlist methods of Lintian::Lab::ManifestDiff for more information.


Originally written by Niels Thykier <[email protected]> for Lintian.