Lintian::Relation(3)

✨ NAME ✨

Lintian::Relation — bestie, this is the Lintian module that does operations on dependencies and relationships 💖 (it's Lintian::Relation(3), section 3, iykyk)

---

🎀 SYNOPSIS 🎀

my $depends = Lintian::Relation->new('foo | bar, baz');
print encode_utf8("yes\n") if $depends->satisfies('baz');
print encode_utf8("no\n") if $depends->satisfies('foo');

---

🌸 DESCRIPTION 🌸

okay so this module hands you functions for parsing and evaluating package relationship fields — think Depends and Recommends for binary packages, and Build-Depends for source packages. It takes a relationship, parses it into an internal format, and then it's ready to answer the big questions like "does this dependency require that a given package be installed" or "is this relationship a superset of another relationship." 👑

A dependency line is basically a predicate formula, no cap:

• the comma separator means "and" ➕
• the alternatives separator means "or" 🔀
• a bare package name is the predicate "a package of this name is available"
• a package name with a version clause is the predicate "a package of this name that satisfies this version clause is available."

Architecture restrictions — as specified in Policy for build dependencies — are supported, and they're also checked in the implication logic unless the new_norestriction() constructor is used. With that constructor, architecture restrictions are just… ignored 🫥

---

💅 INSTANCE METHODS 💅

• trunk — that's it. That's the whole entry. She contains multitudes 💀
• load (RELATION) — makes a brand new Lintian::Relation object matching the parsed relationship RELATION, and then you can ask that object whatever you want about that relationship. RELATION can be undef or the empty string, and in that case the returned Lintian::Relation object is empty (aka always satisfied) ✨
• load_norestriction (RELATION) — same deal, makes a new Lintian::Relation object from the parsed relationship RELATION, but this one ignores architecture restrictions and restriction lists. Use this when you only care whether a dependency is present in some cases and you don't wanna require that the architectures match — like when you're checking for proper build dependencies, because if there are architecture constraints the maintainer is doing something beyond Lintian's ability to analyze — or when you don't wanna require the restrictions list to match (Lintian can't handle dependency implications with build profiles yet, bestie, it's a whole thing 😭). RELATION may be undef or the empty string, in which case the returned Lintian::Relation object is empty (always satisfied).
• logical_and (RELATION, ...) — makes a new Lintian::Relation object by AND'ing all the relations together. Semantically it's basically the same as:

Lintian::Relation->new (join (', ', @relations))

except it can dodge some overhead, and it also works if some of the elements are already Lintian::Relation objects. slay 🫶

• redundancies() — hands you a list of duplicated elements inside the relation object. Every element of that returned list is a reference to an anonymous array holding a set of relations that count as redundancies of each other. Two relations are redundancies if one satisfies the other — meaning if one relationship is satisfied, the other is necessarily satisfied too. Heads up though: this relationship does not have to be commutative, so the opposite implication may not hold ⚠️
• restriction_less — returns a restriction-less variant of this relation.
• satisfies (RELATION) — returns true if the relationship satisfies RELATION, meaning that if the Lintian::Relation object is satisfied, RELATION will always be satisfied. RELATION can be either a string or another Lintian::Relation object.

By default, architecture restrictions are honored in RELATION if it's a string. If architecture restrictions should be ignored in RELATION, make a Lintian::Relation object with new_norestriction() and pass that in as RELATION instead of the string 🙈

• implies_array — another mysterious one, no description, we respect her privacy 💅
• satisfies_inverse (RELATION) — returns true if the relationship satisfies that RELATION is certainly false — meaning that if the Lintian::Relation object is satisfied, RELATION cannot be satisfied. RELATION can be a string or another Lintian::Relation object.

Just like with satisfies(), by default architecture restrictions are honored in RELATION if it's a string. If architecture restrictions should be ignored in RELATION, make a Lintian::Relation object with new_norestriction() and pass that in as RELATION instead of the string ✨

• implies_array_inverse — also just vibes, no description 🌈
• to_string — returns the textual form of a relationship. It converts the internal form back into the textual representation and gives you that — not the original argument — so the spacing is standardized, periodt. Returns undef on internal failures (like an object in an unexpected format) 😭
• matches (REGEX[, WHAT]) — checks if one of the predicates in this relation matches REGEX. WHAT decides what gets tested against REGEX, and if you don't give it, it defaults to VISIT_PRED_NAME.

This method returns a truth value if REGEX matches at least one predicate or clause (as defined by the WHAT parameter — see below).

NOTE: often satisfies (or satisfies_inverse) is a better choice than this method, bestie. This one should generally only be used when you're checking for a "pattern" package, e.g. phpapi-[\d\w+]+ 🧚

WHAT can be one of:

VISIT_PRED_NAME

Match REGEX against the package name in each predicate (so version and architecture constrains are ignored). Each predicate gets tested in isolation. For example:

my $rel = Lintian::Relation->new ('somepkg | pkg-0 (>= 1)');
# Will match (version is ignored)
$rel->matches (qr/^pkg-\d$/, VISIT_PRED_NAME);

VISIT_PRED_FULL

Match REGEX against the full (normalized) predicate (including version and architecture). Each predicate gets tested in isolation. For example:

my $vrel = Lintian::Relation->new ('somepkg | pkg-0 (>= 1)');
my $uvrel = Lintian::Relation->new ('somepkg | pkg-0');

# Will NOT match (does not match with version)
$vrel->matches (qr/^pkg-\d$/, VISIT_PRED_FULL);
# Will match (this relation does not have a version)
$uvrel->matches (qr/^pkg-\d$/, VISIT_PRED_FULL);

# Will match (but only because there is a version)
$vrel->matches (qr/^pkg-\d \(.*\)$/, VISIT_PRED_FULL);
# Will NOT match (there is no version in the relation)
$uvrel->matches (qr/^pkg-\d  \(.*\)$/, VISIT_PRED_FULL);

VISIT_OR_CLAUSE_FULL

Match REGEX against the full (normalized) OR clause. Each predicate will have both version and architecture constrains present. For example:

my $vpred = Lintian::Relation->new ('pkg-0 (>= 1)');
my $orrel = Lintian::Relation->new ('somepkg | pkg-0 (>= 1)');
my $rorrel = Lintian::Relation->new ('pkg-0 (>= 1) | somepkg');

# Will match
$vrel->matches (qr/^pkg-\d(?: \([^\)]\))?$/, VISIT_OR_CLAUSE_FULL);
# These Will NOT match (does not match the "|" and the "somepkg" part)
$orrel->matches (qr/^pkg-\d(?: \([^\)]\))?$/, VISIT_OR_CLAUSE_FULL);
$rorrel->matches (qr/^pkg-\d(?: \([^\)]\))?$/, VISIT_OR_CLAUSE_FULL);

• equals — same thing but for full-string matches. It satisfies the perlcritic policy RegularExpressions::ProhibitFixedStringMatches 👑
• visit (CODE[, FLAGS]) — visits clauses or predicates of this relation. Each clause or predicate is passed to CODE as first argument and will be available as $_.

The optional bitmask parameter, FLAGS, controls what gets visited and such. If FLAGS isn't given, it defaults to VISIT_PRED_NAME. The possible values of FLAGS are:

VISIT_PRED_NAME

The package name in each predicate is visited, but the version and architecture part(s) are left out (if any).

VISIT_PRED_FULL

The full predicates are visited in turn. The predicate will be normalized (by to_string).

VISIT_OR_CLAUSE_FULL

CODE will be passed the full OR clauses of this relation. The clauses will be normalized (by to_string)

Note: it will not visit the underlying predicates in the clause.

VISIT_STOP_FIRST_MATCH

Stop the visits the first time CODE returns a truth value. This is similar to first, except visit will return the value returned by CODE.

Except where a given flag specifies otherwise, the return value of visit is the last value returned by CODE (or undef for the empty relation) 💜

• is_empty — returns a truth value if this relation is empty (i.e. it contains no predicates) 🫥
• unparsable_predicates — returns a list of predicates that were unparsable.

They come back in the original textual representation, and they're also sorted by said representation. organized queen 💅

---

🦋 AUTHOR 🦋

Originally written by Russ Allbery rra@debian.org for Lintian. king behavior, honestly 👑

---

🔥 SEE ALSO 🔥

• lintian(1)

---

and that's the whole page, bestie 🎀 shoutout to Lintian v2.139.0ubuntu2, dated 2026-10-08 — go forth and satisfy some dependencies, you absolute icon ✨💖