LIBSOLV-BINDINGS(3)

📦
version 0.7.41 · 7 versions
, in arch rolling, fedora 44

💖 LIBSOLV-BINDINGS 💖

okay so bestie, welcome to libsolv-bindings, aka the part of the LIBSOLV manual that lets you talk to libsolv from literally Not C. pull up a chair, we're doing this 🫶

✨ NAME ✨

libsolv-bindings — access libsolv from perl/python/ruby 🐍💎

🌸 DESCRIPTION 🌸

Libsolv's language bindings serve you an abstract, object orientated interface to the library. the languages that are currently supported are perl, python, ruby and tcl. and here's the deal with all the example code below: unless we're in one of the specifics sections (where, obviously, it's language-specific), each snippet lists the "C-ish" interface first, then the syntax for perl, python, and ruby, in that exact order. no cap. 👑

🐪 PERL SPECIFICS

Libsolv's perl bindings can be loaded with this statement right here:

use solv;

Objects are either created by calling the new() method on a class, or they get returned to you by calling methods on other objects. it's giving ✨object oriented✨:

my $pool = solv::Pool->new();
my $repo = $pool->add_repo("my_first_repo");

Swig encapsulates all objects as tied hashes, so the attributes can be accessed by just treating the object as a standard hash reference:

$pool->{appdata} = 42;
printf "appdata is %d\n", $pool->{appdata};

a special exception to this rule are iterator objects — those are encapsulated as tied arrays so that it's actually possible to iterate with a for() statement:

my $iter = $pool->solvables_iter();
for my $solvable (@$iter) { ... };

and as a downside of this whole approach, iterator objects cannot have attributes. sad but true 😭

if an array needs to be passed to a method, it's usually done by reference, and if a method returns an array, it returns it on the perl stack:

my @problems = $solver->solve(\@jobs);

due to a bug in swig, stringification does not work for libsolv's objects. instead, you have to call the object's str() method:

print $dep->str() . "\n";

Swig implements all constants as numeric variables (instead of the more natural constant subs), so don't forget the leading $ when you're accessing a constant. also don't forget to prepend the namespace of the constant:

$pool->set_flag($solv::Pool::POOL_FLAG_OBSOLETEUSESCOLORS, 1);

🐍 PYTHON SPECIFICS

The python bindings can be loaded with:

import solv

Objects are either created by calling the constructor method for a class, or they are returned by calling methods on other objects:

pool = solv.Pool()
repo = pool.add_repo("my_first_repo")

Attributes can be accessed as usual:

pool.appdata = 42
print "appdata is %d" % (pool.appdata)

Iterators also work as expected, bestie:

for solvable in pool.solvables_iter():

Arrays are passed and returned as list objects:

jobs = []
problems = solver.solve(jobs)

The bindings define stringification for many classes, and some also have a repr method to ease debugging:

print dep
print repr(repo)

Constants are attributes of the corresponding classes:

pool.set_flag(solv.Pool.POOL_FLAG_OBSOLETEUSESCOLORS, 1);

💎 RUBY SPECIFICS

The ruby bindings can be loaded with:

require 'solv'

Objects are either created by calling the new method on a class, or they are returned by calling methods on other objects. note that all classes start with an uppercase letter in ruby, so the class is called Solv:

pool = Solv::Pool.new
repo = pool.add_repo("my_first_repo")

Attributes can be accessed as usual:

pool.appdata = 42
puts "appdata is #{pool.appdata}"

Iterators also work as expected:

for solvable in pool.solvables_iter() do ...

Arrays are passed and returned as array objects:

jobs = []
problems = solver.solve(jobs)

Most classes define a to_s method, so objects can be easily stringified. Many also define an inspect() method:

puts dep
puts repo.inspect

Constants live in the namespace of the class they belong to:

pool.set_flag(Solv::Pool::POOL_FLAG_OBSOLETEUSESCOLORS, 1);

and note that boolean methods have an added trailing ?, just to be consistent with other ruby modules:

puts "empty" if repo.isempty?

🎀 TCL SPECIFICS

Libsolv's tcl bindings can be loaded with the following statement:

package require solv

Objects are either created by calling a class name prefixed with new_, or they are returned by calling methods on other objects:

set pool [solv::new_Pool]
set repo [$pool add_repo "my_first_repo"]

Swig provides a cget method to read object attributes, and a configure method to write them:

$pool configure -appdata 42
puts "appdata is [$pool cget -appdata]"

The tcl bindings provide a little helper to work with iterators in a foreach style:

set iter [$pool solvables_iter]
solv::iter s $iter { ... }

libsolv's arrays are mapped to tcl's lists:

set jobs [list $job1 $job2]
set problems [$solver solve $jobs]
puts "We have [llength $problems] problems..."

Stringification is done by calling the object's str method:

puts [$dep str]

there is one exception though: you have to use stringify for Datamatch objects, because swig reports a clash with the str attribute 🙈

Some classes also support a == method for equality tests, and a != method.

Swig implements all constants as numeric variables, and constants belonging to a libsolv class are prefixed with the class name:

$pool set_flag $solv::Pool_POOL_FLAG_OBSOLETEUSESCOLORS 1
puts [$solvable lookup_str $solv::SOLVABLE_SUMMARY]

🌙 LUA SPECIFICS

Libsolv's lua bindings can be loaded with the following statement:

require("solv")

Objects are either created by calling the constructor method for a class, or they are returned by calling methods on other objects:

pool = solv.Pool()
repo = pool:add_repo("my_first_repo")

note the :method syntax, which is what makes lua add the object as the first argument 👑

Attributes can be accessed as usual:

pool.appdata = 42
print("appdata is "..pool.appdata)

Iterators also work as expected:

for solvable in pool.solvables do ...

but heads up: some functions return a table instead of an iterator, so you need to use ipairs for iteration:

for _,solvable in ipairs(job.solvables()) do ...

Arrays are passed and returned as tables:

jobs = {}
problems = solver.solve(jobs)
if #problems != 0 then ...

The bindings define a __tostring method for many classes:

print(dep)
print(("Package: %s"):format(solvable))

Constants live in the namespace of the class they belong to:

pool:set_flag(Solv.Pool.POOL_FLAG_OBSOLETEUSESCOLORS, 1);

👑 THE SOLV CLASS 👑

This is the main namespace of the library. you literally cannot create objects of this type — it's not that kind of class — but it contains some very useful constants. 💅

⭐ CONSTANTS ⭐

Relational flag constants, and the first three can be or-ed together:

  • REL_LT — the "less than" bit
  • REL_EQ — the "equals to" bit
  • REL_GT — the "greater than" bit
  • REL_ARCH — used for relations that describe an extra architecture filter, the version part of the relation is interpreted as architecture.

Special Solvable Ids:

  • SOLVID_META — access the meta section of a repository or repodata area. This is like an extra Solvable that has the Id SOLVID_META.
  • SOLVID_POS — use the data position stored inside of the pool instead of accessing some solvable by Id. The bindings have the Datapos objects as an abstraction mechanism, so you most likely do not need this constant.

Constant string Ids:

  • ID_NULL — always zero
  • ID_EMPTY — always one, describes the empty string
  • SOLVABLE_NAME — the keyname Id of the name of the solvable.
  • ... — see the libsolv-constantids manpage for a list of fixed Ids.

🦋 THE POOL CLASS 🦋

The pool is libsolv's central resource manager, aka the main character. A pool consists of Solvables, Repositories, Dependencies, each indexed by Ids. 🌈

💜 CLASS METHODS 💜

Pool *Pool()
my $pool = solv::Pool->new();
pool = solv.Pool()
pool = Solv::Pool.new()

Create a new pool instance. In most cases you just need one pool. note that the returned object "owns" the pool, i.e. if the object is freed, the pool is also freed. You can use the disown method to break this ownership relation.

🎀 ATTRIBUTES 🎀

void *appdata;                  /* read/write */
$pool->{appdata}
pool.appdata
pool.appdata

Application specific data that may be used in any way by the code using the pool.

Solvable solvables[];           /* read only */
my $solvable = $pool->{solvables}->[$solvid];
solvable = pool.solvables[solvid]
solvable = pool.solvables[solvid]

Look up a Solvable by its id.

Repo repos[];                   /* read only */
my $repo = $pool->{repos}->[$repoid];
repo = pool.repos[repoid]
repo = pool.repos[repoid]

Look up a Repository by its id.

Repo *installed;                /* read/write */
$pool->{installed} = $repo;
pool.installed = repo
pool.installed = repo

Define which repository contains all the installed packages.

const char *errstr;             /* read only */
my $err = $pool->{errstr};
err = pool.errstr
err = pool.errstr

Return the last error string that was stored in the pool.

✨ CONSTANTS ✨

  • POOL_FLAG_PROMOTEEPOCH — promote the epoch of the providing dependency to the requesting dependency if it does not contain an epoch. Used at some time in old rpm versions, modern systems should never need this. (it's giving legacy 💀)
  • POOL_FLAG_FORBIDSELFCONFLICTS — disallow the installation of packages that conflict with themselves. Debian always allows self-conflicting packages, rpm used to forbid them but switched to also allowing them since rpm-4.9.0.
  • POOL_FLAG_OBSOLETEUSESPROVIDES — make obsolete type dependency match against provides instead of just the name and version of packages. Very old versions of rpm used the name/version, then it got switched to provides and later switched back again to just name/version.
  • POOL_FLAG_IMPLICITOBSOLETEUSESPROVIDES — an implicit obsoletes is the internal mechanism to remove the old package on an update. The default is to remove all packages with the same name, rpm-5 switched to also removing packages providing the same name.
  • POOL_FLAG_OBSOLETEUSESCOLORS — rpm's multilib implementation distinguishes between 32bit and 64bit packages (the terminology is that they have a different color). If obsoleteusescolors is set, packages with different colors will not obsolete each other.
  • POOL_FLAG_IMPLICITOBSOLETEUSESCOLORS — okay so this one is the same as POOL_FLAG_OBSOLETEUSESCOLORS, bestie, but it's the flag you use to find out whether packages with the same name can be installed in parallel. On current Fedora systems, POOL_FLAG_OBSOLETEUSESCOLORS should be false and POOL_FLAG_IMPLICITOBSOLETEUSESCOLORS should be true — and that's literally the default if FEDORA is defined when libsolv is compiled. 💖
  • POOL_FLAG_NOINSTALLEDOBSOLETES — since version 4.9.0, rpm considers the obsoletes of installed packages when it's checking for dependency conflicts. So basically you may not install a package that's obsoleted by some other installed package unless you also erase that other package. No cap.
  • POOL_FLAG_HAVEDISTEPOCH — Mandriva added a whole new field called distepoch, and it gets checked in version comparison if the epoch/version/release of two packages are the same. iconic behavior tbh.
  • POOL_FLAG_NOOBSOLETESMULTIVERSION — so if a package is installed in multiversion mode, rpm used to ignore both the implicit obsoletes and the obsolete dependency of a package. That got changed to ignoring just the implicit obsoletes, which means you may install multiple versions of the same name, but obsoleted packages still get removed. 👑
  • POOL_FLAG_ADDFILEPROVIDESFILTERED — makes the addfileprovides method only add files from the standard locations (i.e. the “bin” and “etc” directories). This is a whole vibe if you have only a few packages that use non-standard file dependencies but you still want the fast speed that addfileprovides() generates. 💅
  • POOL_FLAG_NOWHATPROVIDESAUX — disables the creation of the auxiliary whatprovides index. Saves a bit of memory, but it also makes the whatprovides lookups a bit slower. Pick your struggle, fr.
  • POOL_FLAG_WHATPROVIDESWITHDISABLED — makes the whatprovides index also contain disabled packages. Meaning: you don't need to recreate the index if a package is enabled/disabled, i.e. the pool→considered bitmap is changed. so convenient.
  • POOL_FLAG_NOWHATPROVIDESSHRINK — do not unify identical provider lists when the whatprovides index is created. Creating the index goes faster, at the price of using more memory. trade-offs, bestie! 😭

✨ METHODS ✨

void free()

$pool->free();
pool.free()
pool.free()

Force a free of the pool. > After this call, you must not access any object that still references the pool. like, seriously, don't. 💀

void disown()

$pool->disown();
pool.disown()
pool.disown()

Break the ownership relation between the binding object and the pool. After this call the pool will not get freed even if the object goes out of scope. Which also means you have to manually call the free method to free the pool data. you're the parent now 🫶

void setdebuglevel(int level)

$pool->setdebuglevel($level);
pool.setdebuglevel(level)
pool.setdebuglevel(level)

Set the debug level. A value of zero means no debug output, and the higher the value, the more output gets generated. gossip levels, basically 💬

int set_flag(int flag, int value)

my $oldvalue = $pool->set_flag($flag, $value);
oldvalue = pool.set_flag(flag, value)
oldvalue = pool.set_flag(flag, value)

int get_flag(int flag)

my $value = $pool->get_flag($flag);
value = pool.get_flag(flag)
value = pool.get_flag(flag)

Set/get a pool specific flag. The flags define how the system works — e.g. how the package manager treats obsoletes. The default flags should be sane for most applications, but in some cases you may want to tweak a flag, for example if you want to solve package dependencies for some other system. (it's giving main character, but for another distro ✨)

void set_rootdir(const char *rootdir)

$pool->set_rootdir(rootdir);
pool.set_rootdir(rootdir)
pool.set_rootdir(rootdir)

const char *get_rootdir()

my $rootdir = $pool->get_rootdir();
rootdir = pool.get_rootdir()
rootdir = pool.get_rootdir()

Set/get the rootdir to use. Super useful if you want package management to work only in some directory — for example if you want to set up a chroot jail. > Just so you know: the rootdir will only be prepended to file paths if the REPO_USE_ROOTDIR flag is used. 🎀

void setarch(const char *arch = 0)

$pool->setarch();
pool.setarch()
pool.setarch()

Set the architecture for your system. The architecture is what determines which packages are installable. It defaults to the result of uname -m. 🦋

Repo add_repo(const char *name)

$repo = $pool->add_repo($name);
repo = pool.add_repo(name)
repo = pool.add_repo(name)

Add a Repository with the specified name to the pool. The repository is empty on creation, so use the repository methods to populate it with packages. empty vessel, no thoughts, head empty 🌸

Repoiterator repos_iter()

for my $repo (@{$pool->repos_iter()})
for repo in pool.repos_iter():
for repo in pool.repos_iter()

Iterate over the existing repositories. go little loop go 🧚

Solvableiterator solvables_iter()

for my $solvable (@{$pool->solvables_iter()})
for solvable in pool.solvables_iter():
for solvable in pool.solvables_iter()

Iterate over the existing solvables. same energy, different list 💜

Dep Dep(const char *str, bool create = 1)

my $dep = $pool->Dep($string);
dep = pool.Dep(string)
dep = pool.Dep(string)

Create an object describing a string or dependency. If the string is currently not in the pool and create is false, undef/None/nil is returned. no notes, that's just how it is 🙈

void addfileprovides()

$pool->addfileprovides();
pool.addfileprovides()
pool.addfileprovides()

Id *addfileprovides_queue()

my @ids = $pool->addfileprovides_queue();
ids = pool.addfileprovides_queue()
ids = pool.addfileprovides_queue()

Some package managers like rpm allow dependencies on files contained in other packages. To let libsolv deal with those dependencies in an efficient way, you need to call the addfileprovides method after creating and reading all repositories. This method scans all dependency for file names and then scans all packages for matching files. If a filename has been matched, it gets added to the provides list of the corresponding package. The addfileprovides_queue variant works the same way but returns an array containing all file dependencies. That info can be stored in the meta section of the repositories to speed up the next time the repository is loaded and addfileprovides is called. speed-run strats ⭐

void createwhatprovides()

$pool->createwhatprovides();
pool.createwhatprovides()
pool.createwhatprovides()

Create the internal “whatprovides” hash over all of the provides of all installable packages. > This method must be called before doing any lookups on provides. It's encouraged to do it right after all repos are set up, usually right after the call to addfileprovides(). order matters, bestie 🔥

Solvable *whatprovides(DepId dep)

my @solvables = $pool->whatprovides($dep);
solvables = pool.whatprovides(dep)
solvables = pool.whatprovides(dep)

Return all solvables that provide the specified dependency. You can use either a Dep object or a simple Id as the argument. flexible, we love to see it 💖

Solvable *best_solvables(Solvable *solvables, int flags = 0)

my @solvables = $pool->best_solvables($solvables);
solvables = pool.best_solvables(solvables)
solvables = pool.best_solvables(solvables)

Filter a list of solvables by repo priority, architecture and version. the vibe check for packages 😌

Solvable *whatcontainsdep(Id keyname, DepId dep, Id marker = -1)

my @solvables = $pool->whatcontainsdep($keyname, $dep);
solvables = pool.whatcontainsdep(keyname, dep)
solvables = pool.whatcontainsdep(keyname, dep)

Return all solvables for which keyname contains the dependency.

Solvable *whatmatchesdep(Id keyname, DepId dep, Id marker = -1)

my @solvables = $pool->whatmatchesdep($keyname, $sdep);
solvables = pool.whatmatchesdep(keyname, dep)
solvables = pool.whatmatchesdep(keyname, dep)

Return all solvables that have dependencies in keyname that match the dependency.

Solvable *whatmatchessolvable(Id keyname, Solvable solvable, Id marker = -1)

my @solvables = $pool->whatmatchessolvable($keyname, $solvable);
solvables = pool.whatmatchessolvable(keyname, solvable)
solvables = pool.whatmatchessolvable(keyname, solvable)

Return all solvables that match package dependencies against *solvable*’s provides.

Id *matchprovidingids(const char *match, int flags)

my @ids = $pool->matchprovidingids($match, $flags);
ids = pool.matchprovidingids(match, flags)
ids = pool.matchprovidingids(match, flags)

Search the names of all provides and return the ones matching the specified string. See the Dataiterator class for the allowed flags. 👀

Id towhatprovides(Id *ids)

my $offset = $pool->towhatprovides(\@ids);
offset = pool.towhatprovides(ids)
offset = pool.towhatprovides(ids)

“Internalize” an array containing Ids. The returned value can be used to create solver jobs working on a specific set of packages. See the Solver class for more info.

void set_namespaceproviders(DepId ns, DepId evr, bool value = 1)

$pool->set_namespaceproviders($ns, $evr, 1);
pool.set_namespaceproviders(ns, evr, True)
pool.set_namespaceproviders(ns, evr, true)

Manually set a namespace provides entry in the whatprovides index.

void flush_namespaceproviders(DepId ns, DepId evr)

$pool->flush_namespaceproviders($ns, $evr);
$pool.flush_namespaceproviders(ns, evr)
$pool.flush_namespaceproviders(ns, evr)

Flush the cache of all namespaceprovides matching the specified namespace dependency. You can use zero as a wildcard argument. 🪄

bool isknownarch(DepId id)

my $bool = $pool->isknownarch($id);
bool = pool.isknownarch(id)
bool = pool.isknownarch?(id)

Return true if the specified Id describes a known architecture.

Solver Solver()

my $solver = $pool->Solver();
solver = pool.Solver()
solver = pool.Solver()

Create a new solver object. ✨

Job Job(int how, Id what)

my $job = $pool->Job($how, $what);
job = pool.Job(how, what)
job = pool.Job(how, what)

Create a new Job object. Kind of low level, in most cases you would instead use a Selection or Dep job constructor. that's the manual route, respect 🫡

Selection Selection()

my $sel = $pool->Selection();
sel = pool.Selection()
sel = pool.Selection()

Create an empty selection. Useful as a starting point for merging other selections. blank canvas energy 🎨

Selection Selection_all()

my $sel = $pool->Selection_all();
sel = pool.Selection_all()
sel = pool.Selection_all()
  • select — builds you a whole Selection stuffed with every package. ✨ lowkey the perfect starting point for intersecting with other selections, or for update/distupgrade kind of jobs.
Selection select(const char *name, int flags)
my $sel = $pool->select($name, $flags);
sel = pool.select(name, flags)
sel = pool.select(name, flags)
  • matchdeps — makes a selection by matching packages against the string you hand it. go peek at the Selection class for the flags list + how to spin solver jobs out of a selection. 🎀
Selection matchdeps(const char *name, int flags, Id keyname, Id marker = -1)
my $sel = $pool->matchdeps($name, $flags, $keyname);
sel = pool.matchdeps(name, flags, keyname)
sel = pool.matchdeps(name, flags, keyname)
  • matchdepid — matches package dependencies against the string. reach for this when you want to match dep types other than “provides”. 👑
Selection matchdepid(DepId dep, int flags, Id keyname, Id marker = -1)
my $sel = $pool->matchdepid($dep, $flags, $keyname);
sel = pool.matchdepid(dep, flags, keyname)
sel = pool.matchdepid(dep, flags, keyname)
  • matchsolvable — matches package dependencies against the specified dependency. lowkey faster than matchdeps and it plays nice with complex dependencies 🦋. the tradeoff? you can't use globs and no case-insensitive matching. 🙈
Selection matchsolvable(Solvable solvable, int flags, Id keyname, Id marker = -1)
my $sel = $pool->matchsolvable($solvable, $flags, $keyname);
sel = pool.matchsolvable(solvable, flags, keyname)
sel = pool.matchsolvable(solvable, flags, keyname)
  • setpooljobs / getpooljobs — get/set the fixed jobs parked in the pool. these get auto-appended to literally all solver jobs, and they're meant for fixed configurations — like which packages can be multiversion installed, which packages were userinstalled, or which packages must not be erased. 💅
void setpooljobs(Jobs *jobs)
$pool->setpooljobs(\@jobs);
pool.setpooljobs(jobs)
pool.setpooljobs(jobs)

Job *getpooljobs()
@jobs = $pool->getpooljobs();
jobs = pool.getpooljobs()
jobs = pool.getpooljobs()
  • set_loadcallback — set the callback function that fires when repository metadata needs to be loaded on demand. to use this lil feature you gotta create repodata stubs that tell the library which data exists but isn't loaded yet. then if that data gets accessed later, the callback gets called with a repodata argument 🫶, and you can go load it (maybe even fetch it first from a remote server). the callback should return true if the data has been made available.
void set_loadcallback(Callable *callback)
$pool->setloadcallback(\&callbackfunction);
pool.setloadcallback(callbackfunction)
pool.setloadcallback { |repodata| ... }
  • appdata_disown — bindings only ✨ drops the reference count of the appdata object. you'd use this to break circular references (like when the pool's appdata value points at some meta data structure that holds a pool handle). if you use this incorrectly it can crash your application, so beware 😭. (this method is a no-op for ruby and tcl.)
/* bindings only */
$pool->appdata_disown()
pool.appdata_disown()
pool.appdata_disown()
Id *get_considered_list()
my @ids = $pool->get_considered_list();
ids = pool.get_considered_list()
ids = pool.get_considered_list()

void set_considered_list(Id *ids)
$pool->set_considered_list(\@ids);
pool.set_considered_list(ids)
pool.set_considered_list(ids)
  • get_considered_list / set_considered_list — get/set the list of solvables that are eligible for installation. 📝 heads up: you gotta recreate the whatprovides hash after you change the list.
Id *get_disabled_list()
my @ids = $pool->get_disabled_list();
ids = pool.get_disabled_list()
ids = pool.get_disabled_list()

void set_disabled_list(Id *ids)
$pool->set_disabled_list(\@ids);
pool.set_disabled_list(ids)
pool.set_disabled_list(ids)
  • get_disabled_list / set_disabled_list — get/set the list of solvables that are not eligible for installation. it's basically the inverse of those “considered” methods up there — so calling set_disabled_list() with an empty list makes all solvables eligible for installation 🌈. also: you need to recreate the whatprovides hash after changing the list too.
  • solvableset2str — returns a string describing a list of solvables. it tries to shrink the output by using version ranges where it can. 💖
const char *solvableset2str(Solvable *solvables)
my $str = $pool->solvableset2str($solvables);
str = pool.solvableset2str(solvables)
str = pool.solvableset2str(solvables)

🌸 DATA RETRIEVAL METHODS 🌸

okay so in all the functions below, the keyname argument tells it what to retrieve. for the standard cases you can just use the available Id constants. for example, this:

$solv::SOLVABLE_SUMMARY
solv.SOLVABLE_SUMMARY
Solv::SOLVABLE_SUMMARY

selects the “Summary” entry of a solvable. and then the solvid argument picks out the solvable you want by Id. 💅

const char *lookup_str(Id solvid, Id keyname)
my $string = $pool->lookup_str($solvid, $keyname);
string = pool.lookup_str(solvid, keyname)
string = pool.lookup_str(solvid, keyname)

Id lookup_id(Id solvid, Id keyname)
my $id = $pool->lookup_id($solvid, $keyname);
id = pool.lookup_id(solvid, keyname)
id = pool.lookup_id(solvid, keyname)

unsigned long long lookup_num(Id solvid, Id keyname, unsigned long long notfound = 0)
my $num = $pool->lookup_num($solvid, $keyname);
num = pool.lookup_num(solvid, keyname)
num = pool.lookup_num(solvid, keyname)

bool lookup_void(Id solvid, Id keyname)
my $bool = $pool->lookup_void($solvid, $keyname);
bool = pool.lookup_void(solvid, keyname)
bool = pool.lookup_void(solvid, keyname)

Id *lookup_idarray(Id solvid, Id keyname)
my @ids = $pool->lookup_idarray($solvid, $keyname);
ids = pool.lookup_idarray(solvid, keyname)
ids = pool.lookup_idarray(solvid, keyname)

Chksum lookup_checksum(Id solvid, Id keyname)
my $chksum = $pool->lookup_checksum($solvid, $keyname);
chksum = pool.lookup_checksum(solvid, keyname)
chksum = pool.lookup_checksum(solvid, keyname)

lookup functions, bestie 💖. they return the data element stored in the specified solvable. ngl you should probably use the methods of the Solvable class instead.

Dataiterator Dataiterator(Id keyname, const char *match = 0, int flags = 0)
my $di = $pool->Dataiterator($keyname, $match, $flags);
di = pool.Dataiterator(keyname, match, flags)
di = pool.Dataiterator(keyname, match, flags)

Dataiterator Dataiterator_solvid(Id solvid, Id keyname, const char *match = 0, int flags = 0)
my $di = $pool->Dataiterator($solvid, $keyname, $match, $flags);
di = pool.Dataiterator(solvid, keyname, match, flags)
di = pool.Dataiterator(solvid, keyname, match, flags)

for my $d (@$di)
for d in di:
for d in di

iterate over the matching data elements 🔥. peep the Dataiterator class for the full tea. the Dataiterator method iterates over all solvables in the pool, whereas Dataiterator_solvid only iterates over the one solvable you named.

👑 ID METHODS 👑

these next ones deal with Ids, aka the integers that represent objects in the pool. they're considered “low level” — in most cases you wouldn't use them, you'd use the object orientated methods instead. iykyk 💅

  • id2repo — looks up an existing Repository by id. you can also do this with the repos attribute.
Repo id2repo(Id id)
$repo = $pool->id2repo($id);
repo = pool.id2repo(id)
repo = pool.id2repo(id)
  • id2solvable — looks up an existing Repository by id. you can also do this with the solvables attribute. 🦋
Solvable id2solvable(Id id)
$solvable = $pool->id2solvable($id);
solvable = pool.id2solvable(id)
solvable = pool.id2solvable(id)
  • solvid2str — returns a string describing the Solvable with that id. the string is made of the name, version, and architecture of the Solvable. ✨
const char *solvid2str(Id id)
my $str = $pool->solvid2str($id);
str = pool.solvid2str(id)
str = pool.solvid2str(id)
  • solvidset2str — returns a string describing a list of solvables, and yes it tries to shrink the output with version ranges when it can. 🌈
const char *solvidset2str(Id *solvids)
my $str = $pool->solvidset2str(\@solvids);
str = pool.solvidset2str(solvids)
str = pool.solvidset2str(solvids)
  • str2id / id2str — convert a string into an Id and back again 🙈. if the string isn't currently in the pool and create is false, you get zero back.
Id str2id(const char *str, bool create = 1)
my $id = pool->str2id($string);
id = pool.str2id(string)
id = pool.str2id(string)

const char *id2str(Id id)
$string = pool->id2str($id);
string = pool.id2str(id)
string = pool.id2str(id)
  • rel2id — creates a “relational” dependency. these babies are made of a name part, flags describing the relation, and a version part. the flags are:
$solv::REL_EQ | $solv::REL_GT | $solv::REL_LT
solv.REL_EQ | solv.REL_GT | solv.REL_LT
Solv::REL_EQ | Solv::REL_GT | Solv::REL_LT

so basically, if you want a “<=” relation, you'd use REL_LT | REL_EQ. 💅

Id rel2id(Id name, Id evr, int flags, bool create = 1)
my $id = pool->rel2id($nameid, $evrid, $flags);
id = pool.rel2id(nameid, evrid, flags)
id = pool.rel2id(nameid, evrid, flags)
  • id2langid — makes a language specific Id out of some other id 🌸. all it does is convert the id into a string, append a dot and the language you specified, then convert the whole thing back into an Id.
Id id2langid(Id id, const char *lang, bool create = 1)
my $id = $pool->id2langid($id, $language);
id = pool.id2langid(id, language)
id = pool.id2langid(id, language)
  • dep2str — converts a dependency id into a string. if the id is just a string, this does the same thing as id2str(). for relational dependencies, you get the correct “name relation evr” string. 🎀
const char *dep2str(Id id)
$string = pool->dep2str($id);
string = pool.dep2str(id)
string = pool.dep2str(id)
  • get_idcounts — returns how many string Ids and relation Ids are currently chillin' in the pool. ⭐
unsigned int get_idcounts(unsigned int *OUTPUT)
my ($nstrings, $nrels) = $pool->get_idcounts();
nstrings, nrels = pool.get_idcounts()
location, mediano = pool.get_idcounts()
  • presize_idhashes — presizes those id hashes so they don't have to grow later. 🔥
void presize_idhashes(unsigned int nstrings, unsigned int nrels)
$pool->presize_idhashes($nstrings, $nrels);
pool.presize_idhashes(nstrings, nrels)
pool.presize_idhashes(nstrings, nrels)

Presize the hashes so that nstrings/nrels new strings/relations can be added without needing to grow the hashes. ✨

💖 THE DEPENDENCY CLASS 💖

So like… the dependency class is the object-orientated way to work with strings and dependencies. Internally, dependencies are represented as Ids, i.e. simple numbers. Dependency objects can be constructed by using the Pool's Dep() method. Obsessed, honestly. 🫶

🌸 ATTRIBUTES 🌸

  • Pool *pool; — read only 💅
$dep->{pool}
dep.pool
dep.pool

Back reference to the pool this dependency belongs to. It's giving "who's your parent" energy.

  • Id id; — read only 💅
$dep->{id}
dep.id
dep.id

The id of this dependency. Just a lil number, no cap.

🦋 METHODS 🦋

Dep Rel(int flags, DepId evrid, bool create = 1)
my $reldep = $dep->Rel($flags, $evrdep);
reldep = dep.Rel(flags, evrdep)
reldep = dep.Rel(flags, evrdep)

Create a relational dependency from the caller dependency, the flags, and a dependency describing the "version" part. See the pool's rel2id method for a description of the flags — go look it up bestie, the flags lore lives there. 🔥

Selection Selection_name(int setflags = 0)
my $sel = $dep->Selection_name();
sel = dep.Selection_name()
sel = dep.Selection_name()

Create a Selection from a dependency. The selection consists of all packages that have a name equal to the dependency. If the dependency is of a relational type, the packages version must also fulfill the dependency. Both boxes gotta be checked, periodt. ✅

Selection Selection_provides(int setflags = 0)
my $sel = $dep->Selection_provides();
sel = dep.Selection_provides()
sel = dep.Selection_provides()

Create a Selection from a dependency. This time the selection consists of all packages that have at least one provides matching the dependency. 🎀

const char *str()
my $str = $dep->str();
str = dep.str()
str = dep.str()

Return a string describing the dependency. Iconic behaviour, truly.

<stringification>
my $str = $dep->str;
str = str(dep)
str = dep.to_s

Same as calling the str() method. Literally the same thing, just cuter. 💅

<equality>
if ($dep1 == $dep2)
if dep1 == dep2:
if dep1 == dep2

Two dependencies are equal if they are part of the same pool and have the same ids. Both conditions, no shortcuts, iykyk. 🌈

👑 THE REPOSITORY CLASS 👑

A Repository describes a group of packages, normally coming from the same source. Repositories are created by the Pool's add_repo() method. 🧚

🌸 ATTRIBUTES 🌸

  • Pool *pool; — read only 💅
$repo->{pool}
repo.pool
repo.pool

Back reference to the pool this dependency belongs to.

  • Id id; — read only 💅
$repo->{id}
repo.id
repo.id

The id of the repository.

  • const char *name; — read/write 💖
$repo->{name}
repo.name
repo.name

The repositories name. To libsolv, the name is just a string with no specific meaning. It's not deep, it's just a label bestie. 🙈

  • int priority; — read/write 💖
$repo->{priority}
repo.priority
repo.priority

The priority of the repository. A higher number means that packages of this repository will be chosen over other repositories, even if they have a greater package version. Yeah, it overrides version. Big deal energy. 🔥

  • int subpriority; — read/write 💖
$repo->{subpriority}
repo.subpriority
repo.subpriority

The sub-priority of the repository. This value is compared when the priorities of two repositories are the same. It's useful to make the library prefer on-disk repositories to remote ones. Tie-breaker, bestie. 🎀

  • int nsolvables; — read only 💅
$repo->{nsolvables}
repo.nsolvables
repo.nsolvables

The number of solvables in this repository.

  • void *appdata; — read/write 💖
$repo->{appdata}
repo.appdata
repo.appdata

Application specific data that may be used in any way by the code using the repository. Yours to fill, no rules. ✨

  • Datapos *meta; — read only 💅
$repo->{meta}
repo.meta
repo.meta

Return a Datapos object of the repodata's metadata. You can use the lookup methods of the Datapos class to lookup metadata attributes, like the repository timestamp. 🕰️

⭐ CONSTANTS ⭐

  • REPO_REUSE_REPODATA — Reuse the last repository data area ("repodata") instead of creating a new area.
  • REPO_NO_INTERNALIZE — Do not internalize the added repository data. This is useful if you plan to add more data because internalization is a costly operation. Save your CPU, bestie. 💸
  • REPO_LOCALPOOL — Use the repodata's pool for Id storage instead of the global pool. Useful if you don't want to pollute the global pool with many unneeded ids, like when storing the filelist. Keep your pool clean, cleanse era. 🧼
  • REPO_USE_LOADING — Use the repodata that is currently being loaded instead of creating a new one. This only makes sense if used in a load callback. ⚠️
  • REPO_EXTEND_SOLVABLES — Do not create new solvables for the new data, but match existing solvables and add the data to them. Repository metadata is often split into multiple parts, with one primary file describing all packages and other parts holding information that is normally not needed, like the changelog.
  • REPO_USE_ROOTDIR — Prepend the pool's rootdir to the path when doing file operations.
  • REPO_NO_LOCATION — Do not add a location element to the solvables. Useful if the solvables are not in the final position, so you can add the correct location later in your code. Add it later queen 💅
  • SOLV_ADD_NO_STUBS — Do not create stubs for repository parts that can be downloaded on demand.
  • SUSETAGS_RECORD_SHARES — This is specific to the add_susetags() method. Susetags allows one to refer to already read packages to save disk space. If this data sharing needs to work over multiple calls to add_susetags, you need to specify this flag so that the share information is made available to subsequent calls. Niche but important, fr fr. 🍓

🦋 METHODS 🦋

void free(bool reuseids = 0)
$repo->free();
repo.free()
repo.free()

Free the repository and all solvables it contains. If reuseids is set to true, the solvable ids and the repository id may be reused by the library when added new solvables. Thus you should leave it false if you are not sure that somebody holds a reference. 👀 Big warning vibes — if someone's still holding on, don't do it.

void empty(bool reuseids = 0)
$repo->empty();
repo.empty()
repo.empty()

Free all the solvables in a repository. The repository will be empty after this call. See the free() method for the meaning of reuseids.

bool isempty()
$repo->isempty()
repo.empty()
repo.empty?

Return true if there are no solvables in this repository. Empty like my patience for broken deps. 💀

void internalize()
$repo->internalize();
repo.internalize()
repo.internalize()

Internalize added data. Data must be internalized before it is available to the lookup and data iterator functions. No internalize = no lookup, periodt. ⚠️

bool write(FILE *fp)
$repo->write($fp)
repo.write(fp)
repo.write(fp)

Write a repo as a "solv" file. These files can be read very fast and thus are a good way to cache repository data. Returns false if there was some error writing the file. Caching slay. 🔥

Solvableiterator solvables_iter()
for my $solvable (@{$repo->solvables_iter()})
for solvable in repo.solvables_iter():
for solvable in repo.solvables_iter()

Iterate over all solvables in a repository. 🌈

Repodata add_repodata(int flags = 0)
my $repodata = $repo->add_repodata();
repodata = repo.add_repodata()
repodata = repo.add_repodata()

Add a new repodata area to the repository. This is normally automatically done by the repo_add methods, so you need this method only in very rare circumstances. You probably don't need this, bestie. 🙈

void create_stubs()
$repo->create_stubs();
repo.create_stubs()
repo.create_stubs()

Calls the create_stubs() repodata method for the last repodata of the repository.

bool iscontiguous()
$repo->iscontiguous()
repo.iscontiguous()
repo.iscontiguous?

Return true if the solvables of this repository are all in a single block with no holes, i.e. they have consecutive ids. No gaps, no drama. ✨

Repodata first_repodata()
my $repodata = $repo->first_repodata();
repodata = repo.first_repodata()
repodata = repo.first_repodata()

Checks if all repodatas but the first repodata are extensions, and return the first repodata if this is the case. Useful if you want to do a store/retrieve sequence on the repository to reduce the memory using and enable paging, as this does not work if the repository contains multiple non-extension repodata areas. Heads up! ⚠️

Selection Selection(int setflags = 0)
my $sel = $repo->Selection();
sel = repo.Selection()
sel = repo.Selection()

Create a Selection consisting of all packages in the repository. The whole squad, gathered. 🫶

Dataiterator Dataiterator(Id key, const char *match = 0, int flags = 0)
my $di = $repo->Dataiterator($keyname, $match, $flags);
di = repo.Dataiterator(keyname, match, flags)
di = repo.Dataiterator(keyname, match, flags)
Dataiterator Dataiterator_meta(Id key, const char *match = 0, int flags = 0)
my $di = $repo->Dataiterator_meta($keyname, $match, $flags);
di = repo.Dataiterator_meta(keyname, match, flags)
di = repo.Dataiterator_meta(keyname, match, flags)
for my $d (@$di)
for d in di:
for d in di

Iterate over the matching data elements in this repository. See the Dataiterator class for more information. The Dataiterator() method iterates over all solvables in a repository, whereas the Dataiterator_meta method only iterates over the repository's meta data. Two different vibes, don't mix em up. 💅

<stringification>
my $str = $repo->str;
str = str(repo)
str = repo.to_s

Return the name of the repository, or "Repo#<id>" if no name is set. Fallback era. 🎀

<equality>
if ($repo1 == $repo2)
if repo1 == repo2:
if repo1 == repo2

Two repositories are equal if they belong to the same pool and have the same id.

🛠️ DATA ADD METHODS 🛠️

Solvable add_solvable()
$repo->add_solvable();
repo.add_solvable()
repo.add_solvable()

Add a single empty solvable to the repository. Returns a Solvable object — see the Solvable class for more information. ✨

bool add_solv(const char *name, int flags = 0)
$repo->add_solv($name);
repo.add_solv(name)
repo.add_solv(name)
bool add_solv(FILE *fp, int flags = 0)
$repo->add_solv($fp);
repo.add_solv(fp)
repo.add_solv(fp)

Read a solv file and yeet its whole contents into the repository 💖. These files get written by the write() method, and they're normally used as a fast cache for repository metadata — like the repo's lil pre-chewed snack so it doesn't have to work so hard 🍓.

add_rpmdb 🔥

bool add_rpmdb(int flags = 0)
$repo->add_rpmdb();
repo.add_rpmdb()
repo.add_rpmdb()

Adds the entire contents of the rpm database to the repository. That's it, that's the vibe 💅.

add_rpmdb_reffp ✨

bool add_rpmdb_reffp(FILE *reffp, int flags = 0)
$repo->add_rpmdb_reffp($reffp);
repo.add_rpmdb_reffp(reffp)
repo.add_rpmdb_reffp(reffp)

Same mission as add_rpmdb — the rpm database contents, all of it — but here's the lil glow-up: if you've got a solv file sitting around that has an old version of the database in it, you can pass it as reffp and it speeds up reading 🏃‍♀️💨. Fast cache, iconic behavior.

add_rpm 🎀

Solvable add_rpm(const char *filename, int flags = 0)
my $solvable = $repo->add_rpm($filename);
solvable = repo.add_rpm(filename)
solvable = repo.add_rpm(filename)

Adds the metadata of a single rpm package to the repository. One package, doing its own thing, main character energy 👑.

add_rpmdb_pubkeys 🔑

bool add_rpmdb_pubkeys(int flags = 0)
$repo->add_rpmdb_pubkeys();
repo.add_rpmdb_pubkeys()
repo.add_rpmdb_pubkeys()

Adds all the pubkeys hanging out inside the rpm database to the repository ✨. One thing to note, bestie: newer rpm versions also allow storing those pubkeys in some directory instead of inside the rpm database. Noted 💜.

add_pubkey 🦋

Solvable add_pubkey(const char *keyfile, int flags = 0)
my $solvable = $repo->add_pubkey($keyfile);
solvable = repo.add_pubkey(keyfile)
solvable = repo.add_pubkey(keyfile)

Adds a pubkey from a file to the repository. One key, one file, very straightforward, slay 🔐.

add_rpmmd 🌸

bool add_rpmmd(FILE *fp, const char *language, int flags = 0)
$repo->add_rpmmd($fp, undef);
repo.add_rpmmd(fp, None)
repo.add_rpmmd(fp, nil)

Adds metadata stored in the "rpm-md" format — i.e. the stuff from the files chillin' in the "repodata" directory — to a repository 🫶. The supported files are "primary", "filelists", "other" and "suseinfo".

⚠️ Do not forget to specify REPO_EXTEND_SOLVABLES for extension files like "filelists" and "other". For real. Don't skip it.

Use the language parameter if you have language extension files, otherwise just pass an undef/None/nil parameter and move on with your day 😌.

add_repomdxml 📜

bool add_repomdxml(FILE *fp, int flags = 0)
$repo->add_repomdxml($fp);
repo.add_repomdxml(fp)
repo.add_repomdxml(fp)

Adds the repomd.xml meta description from the "rpm-md" format to the repository. This file is giving ✨ informant ✨ — it holds info about the repository like keywords, plus a whole list of all the database files with their checksums. Everything lands in the "meta" section of the repository, which means no package gets created 💀. It's meta-only, bestie.

add_updateinfoxml 🔧

bool add_updateinfoxml(FILE *fp, int flags = 0)
$repo->add_updateinfoxml($fp);
repo.add_updateinfoxml(fp)
repo.add_updateinfoxml(fp)

Adds the updateinfo.xml file — the one holding all the available maintenance updates — to the repository. Every single update gets created as a special package that has a "patch:" prefix in its name 👑. Cute, weird, but that's the system.

add_deltainfoxml 🧩

bool add_deltainfoxml(FILE *fp, int flags = 0)
$repo->add_deltainfoxml($fp);
repo.add_deltainfoxml(fp)
repo.add_deltainfoxml(fp)

Adds the deltainfo.xml file (it also answers to prestodelta.xml) containing the available delta-rpms to the repository. Just like repomd, the data goes into the "meta" section, so no package gets created 🙈.

add_debdb 🍥

bool add_debdb(int flags = 0)
$repo->add_debdb();
repo.add_debdb()
repo.add_debdb()

Adds the contents of the debian installed package database to the repository 💜.

add_debpackages 📦

bool add_debpackages(FILE *fp, int flags = 0)
$repo->add_debpackages($fp);
repo.add_debpackages(fp)
repo.add_debpackages(fp)

Adds the contents of the debian repository metadata — the "packages" file — to the repository 🌈.

add_deb 🎁

Solvable add_deb(const char *filename, int flags = 0)
my $solvable = $repo->add_deb($filename);
solvable = repo.add_deb(filename)
solvable = repo.add_deb(filename)

Adds the metadata of a single deb package to the repository. One deb, one solvable, no drama ✨.

add_mdk 🌷

bool add_mdk(FILE *fp, int flags = 0)
$repo->add_mdk($fp);
repo.add_mdk(fp)
repo.add_mdk(fp)

Adds the contents of the mageia/mandriva repository metadata — the "synthesis.hdlist" file — to the repository 🫶.

add_mdk_info 📝

bool add_mdk_info(FILE *fp, int flags = 0)
$repo->add_mdk_info($fp);
repo.add_mdk_info(fp)
repo.add_mdk_info(fp)

Extends the packages from the synthesis file with the info.xml and files.xml data ✨.

⚠️ Do not forget to specify REPO_EXTEND_SOLVABLES. Again. I'm serious, bestie, it will not work without it 😭.

add_arch_repo 🏹

bool add_arch_repo(FILE *fp, int flags = 0)
$repo->add_arch_repo($fp);
repo.add_arch_repo(fp)
repo.add_arch_repo(fp)

Adds the contents of the archlinux repository metadata — the ".db.tar" file — to the repository 💙.

add_arch_local 🐧

bool add_arch_local(const char *dir, int flags = 0)
$repo->add_arch_local($dir);
repo.add_arch_local(dir)
repo.add_arch_local(dir)

Adds the contents of the archlinux installed package database to the repository. The dir parameter is usually set to "/var/lib/pacman/local" 📁.

add_content 🌟

bool add_content(FILE *fp, int flags = 0)
$repo->add_content($fp);
repo.add_content(fp)
repo.add_content(fp)

Adds the “content” meta description from the susetags format to the repository. This file spills the tea on the repository — keywords, all that — plus a full list of every database file with checksums 💅. The data goes into the "meta" section of the repository, so no package gets created, bestie. Meta only.

add_susetags 🎡

bool add_susetags(FILE *fp, Id defvendor, const char *language, int flags = 0)
$repo->add_susetags($fp, $defvendor, $language);
repo.add_susetags(fp, defvendor, language)
repo.add_susetags(fp, defvendor, language)

Adds repository metadata in the susetags format to the repository. Just like with add_rpmmd, you can specify a language if you've got language extension files 🌈. And the defvendor parameter hands out a default vendor for all the packages that are missing one — it's usually provided in the content file 🫶.

add_products 🛍️

bool add_products(const char *dir, int flags = 0)
$repo->add_products($dir);
repo.add_products(dir)
repo.add_products(dir)

Adds the installed SUSE products database to the repository. The dir parameter is usually "/etc/products.d" 📂. And that's the whole squad of repo-reading methods, all fed, all thriving 💖.

👑 THE SOLVABLE CLASS 💖

Okay bestie, so a solvable is literally the whole vibe of one single package — all its info in one lil container. Every solvable is claimed by one repo (possessive much ✋), and yeah you can add and fill one in manually if that's your thing, but fr fr, most of the time the repo_add methods are the ones doing the birthing. 🌸

✨ ATTRIBUTES ✨

Repo *repo;                     /* read only */
$solvable->{repo}
solvable.repo
solvable.repo

The repo this solvable calls home. 🏠 (read only, so don't even try)

Pool *pool;                     /* read only */
$solvable->{pool}
solvable.pool
solvable.pool

The pool this solvable lives in — literally the same pool as its repo's. 🔥

Id id;                          /* read only */
$solvable->{id}
solvable.id
solvable.id

The one, the only, the specific id of this solvable. Every solvable got its own. 💅

char *name;                     /* read/write */
$solvable->{name}
solvable.name
solvable.name
char *evr;                      /* read/write */
$solvable->{evr}
solvable.evr
solvable.evr
char *arch;                     /* read/write */
$solvable->{arch}
solvable.arch
solvable.arch
char *vendor;                   /* read/write */
$solvable->{vendor}
solvable.vendor
solvable.vendor

These are the easy-access gotos for the most-used solvable attributes, no cap. Heads up tho: internally they're stored as Ids, not strings. 👀

Id nameid;                      /* read/write */
$solvable->{nameid}
solvable.nameid
solvable.nameid
Id evrid;                       /* read/write */
$solvable->{evrid}
solvable.evrid
solvable.evrid
Id archid;                      /* read/write */
$solvable->{archid}
solvable.archid
solvable.archid
Id vendorid;                    /* read/write */
$solvable->{vendorid}
solvable.vendorid
solvable.vendorid

This is the raw interface to the ids themselves. It's giving "I'm a power user" energy. Obsessed, honestly. Perfect for when you're hunting a specific id and you want to dodge the string-compare overhead entirely (the way that string compare just drags... 😭). 🦋

✨ METHODS ✨

const char *lookup_str(Id keyname)
my $string = $solvable->lookup_str($keyname);
string = solvable.lookup_str(keyname)
string = solvable.lookup_str(keyname)
Id lookup_id(Id keyname)
my $id = $solvable->lookup_id($keyname);
id = solvable.lookup_id(keyname)
id = solvable.lookup_id(keyname)
unsigned long long lookup_num(Id keyname, unsigned long long notfound = 0)
my $num = $solvable->lookup_num($keyname);
num = solvable.lookup_num(keyname)
num = solvable.lookup_num(keyname)
bool lookup_void(Id keyname)
my $bool = $solvable->lookup_void($keyname);
bool = solvable.lookup_void(keyname)
bool = solvable.lookup_void(keyname)
Chksum lookup_checksum(Id keyname)
my $chksum = $solvable->lookup_checksum($keyname);
chksum = solvable.lookup_checksum(keyname)
chksum = solvable.lookup_checksum(keyname)
Id *lookup_idarray(Id keyname, Id marker = -1)
my @ids = $solvable->lookup_idarray($keyname);
ids = solvable.lookup_idarray(keyname)
ids = solvable.lookup_idarray(keyname)
Dep *lookup_deparray(Id keyname, Id marker = -1)
my @deps = $solvable->lookup_deparray($keyname);
deps = solvable.lookup_deparray(keyname)
deps = solvable.lookup_deparray(keyname)

These are the generic lookup methods — they go fetch whatever data is stored under that specific keyname. ✨

The lookup_idarray() one hands you back an array of Ids. Want an array of Dependency objects instead? That's what lookup_deparray is for, bestie. 🫶

Okay so, plot twist: some Id arrays actually contain two parts of data split by a specific marker. Example incoming: the provides array uses the SOLVABLE_FILEMARKER id to keep track of both the ids provided by the package and the ids added by the addfileprovides method. Wow. The lore. 😭

The default value, -1, translates to the correct marker for that keyname and returns the first part of the array. Want the second part? Pass 1. Want everything including the marker itself? Pass 0. Slay. 💅

const char *lookup_location(unsigned int *OUTPUT)
my ($location, $mediano) = $solvable->lookup_location();
location, mediano = solvable.lookup_location()
location, mediano = solvable.lookup_location()

Returns a tuple of the on-media location plus an optional media number for multi-part repositories (iykyk — like repos spawning across multiple DVDs 📀📀). Tuple core.

const char *lookup_sourcepkg()
my $sourcepkg = $solvable->lookup_sourcepkg();
sourcepkg = solvable.lookup_sourcepkg()
sourcepkg = solvable.lookup_sourcepkg()

Gives you back a sourcepkg name associated with the solvable. Simple, iconic, no notes. ✨

Dataiterator Dataiterator(Id keyname, const char *match = 0, int flags = 0)
my $di = $solvable->Dataiterator($keyname, $match, $flags);
di = solvable.Dataiterator(keyname, match, flags)
di = solvable.Dataiterator(keyname, match, flags)
for my $d (@$di)
for d in di:
for d in di

This iterates over the matching data elements. Wanna know more? Check the Dataiterator class section below, bestie. 👑

void add_deparray(Id keyname, DepId dep, Id marker = -1)
$solvable->add_deparray($keyname, $dep);
solvable.add_deparray(keyname, dep)
solvable.add_deparray(keyname, dep)

Adds a brand new dependency to the attributes stored in keyname. One more dep, no big deal. 💖

void unset(Id keyname)
$solvable->unset($keyname);
solvable.unset(keyname)
solvable.unset(keyname)

Deletes the data stored for that specific keyname. Gone. Poof. 🧚

bool installable()
$solvable->installable()
solvable.installable()
solvable.installable?

Returns true if the solvable can actually be installed on the system. And girlie, a solvable is NOT installable if the system doesn't support its architecture — periodt. 🚫

bool isinstalled()
$solvable->isinstalled()
solvable.isinstalled()
solvable.isinstalled?

Returns true if the solvable is already installed on the system. 💅

bool identical(Solvable *other)
$solvable->identical($other)
solvable.identical(other)
solvable.identical?(other)

Returns true if the two solvables are identical. Twin flames fr fr. 👯

int evrcmp(Solvable *other)
$solvable->evrcmp($other)
solvable.evrcmp(other)
solvable.evrcmp(other)

Compares that epoch/version/release energy:

  • Returns -1 if this solvable's evr is less than the other one's,
  • 1 if it's greater,
  • 0 if they're equal.

But bestie, listen — "equal" does not mean the evr is identical. Careful with that. 😭

int matchesdep(Id keyname, DepId id, Id marker = -1)
$solvable->matchesdep($keyname, $dep)
solvable.matchesdep(keyname, dep)
solvable.matchesdep?(keyname, dep)

Returns true if the dependencies stored in keyname match the dependency you specified. A vibe check for deps. ✨

Selection Selection(int setflags = 0)
my $sel = $solvable->Selection();
sel = solvable.Selection()
sel = solvable.Selection()

Creates a Selection containing just this one single solvable. Main character energy, obviously. 👑

const char *str()
my $str = $solvable->str();
str = $solvable.str()
str = $solvable.str()

Returns a string describing the solvable — and it's made up of the name</>, version</>, and architecture of the Solvable. Cute lil summary. 🎀

<stringification>
my $str = $solvable->str;
str = str(solvable)
str = solvable.to_s

Literally the same thing as calling the str() method. Same vibes, different door. 🌈

<equality>
if ($solvable1 == $solvable2)
if solvable1 == solvable2:
if solvable1 == solvable2

Two solvables are equal if they belong to the same pool and have the same ids. That's the whole test. No shortcuts. 💅

🦋 THE DATAITERATOR CLASS 🦋

Dataiterators are your go-to girls for complex string searches or for iterating over arrays. You make them with the constructors over in the Pool, Repo, and Solvable classes. And here's the tea: the Repo and Solvable constructors will limit the search to that specific repository or that specific package. Scope it down, bestie. ✨

⭐ CONSTANTS ⭐

SEARCH_STRING

Return a match if the search string matches the value. 🎯

SEARCH_STRINGSTART

Return a match if the value starts with the search string. 🚀

SEARCH_STRINGEND

Return a match if the value ends with the search string. 🏁

SEARCH_SUBSTRING

Return a match if the search string can be matched somewhere in the value. 🔍

SEARCH_GLOB

Does a glob match of the search string against the value. ✨

SEARCH_REGEX

Does a regular expression match of the search string against the value. 🧠

SEARCH_NOCASE

Ignores case when matching strings. And the best part? It works for all the match types above. Periodt. 💅

SEARCH_FILES

Matches the complete filenames in the file list — not just the base name, bestie. 📁

SEARCH_COMPLETE_FILELIST

When matching the file list, this checks every single file of the package, not just the subset from the primary metadata. Thorough queen. 👑

SEARCH_CHECKSUMS

Allows the matching of checksum entries. 🔐

⭐ METHODS ⭐

void prepend_keyname(Id keyname);
$di->prepend_keyname($keyname);
di.prepend_keyname(keyname)
di.prepend_keyname(keyname)

Does a sub-search in the array stored in keyname. Nesting era. 🪆

void skip_solvable();
$di->skip_solvable();
di.skip_solvable()
di.skip_solvable()

Stops matching the current solvable and moves on to the next one. Not me ✋ — oh wait, yes me, skipping. Moving on. 💅

<iteration>
for my $d (@$di)
for d in di:
for d in di

Iterates through the matches. And if there is a match, the object in d will be of type Datamatch. That's the payoff, bestie. 🎁✨

THE DATAMATCH CLASS

Every value that a dataiterator matches? Yeah, it spawns one of these little guys. One Datamatch per match. No cap. 💖

ATTRIBUTES

  • Pool *pool; (read only) — back pointer to the pool it came from.
$d->{pool}
d.pool
d.pool
  • Repo *repo; (read only) — the repository that's holding the matched object.
$d->{repo}
d.repo
d.repo
  • Solvable *solvable; (read only) — the solvable that contains the value which got matched.
$d->{solvable}
d.solvable
d.solvable
  • Id solvid; (read only) — the id of the solvable that matched.
$d->{solvid}
d.solvid
d.solvid
  • Id key_id; / const char *key_idstr; — the keyname that matched, and you can have it either as an id or as a string. Choose ur fighter ⭐
$d->{key_id}
d.key_id
d.key_id

$d->{key_idstr}
d.key_idstr
d.key_idstr
  • Id type_id; / const char *type_idstr; — the key type of the value that matched, again as either an id or a string.
$d->{type_id}
d.type_id
d.type_id

$d->{type_idstr};
d.type_idstr
d.type_idstr
  • Id id; / Id idstr; — the Id of the value that matched, either as an id or as a string. Heads up bestie: this is only valid for id types. 💅
$d->{id}
d.id
d.id

$d->{idstr}
d.idstr
d.idstr
  • Dep *dep; (read only) — the id of the matched value, converted into a dependency object.
$d->{dep}
d.dep
d.dep
  • const char *str; — the string value that matched. Only valid for string types, ok? Don't come for me otherwise 🫶
$d->{str}
d.str
d.str
  • unsigned long long num; — the numeric value that matched. Only valid for numeric types.
$d->{num}
d.num
d.num
  • unsigned int num2; — the secondary numeric value that matched, for types that carry two values at once (yes, those exist).
$d->{num2}
d.num2
d.num2
  • unsigned int binary; — the value in raw binary form. Iconic for checksums and any other data that simply cannot be a string. 😭
$d->{binary}
d.binary
d.binary

METHODS

  • Datapos pos() — the position object of the current match. If it's an array type you can use it to do sub-searches starting right at the match. Peep the Datapos class for the deets.
my $pos = $d->pos();
pos = d.pos()
pos = d.pos()
  • Datapos parentpos() — the position object of the array containing the current match. Also good for sub-searches; again, Datapos class has the lore.
my $pos = $d->parentpos();
pos = d.parentpos()
pos = d.parentpos()
  • <stringification> — hands you back the stringification of the matched value. And ngl, what that string looks like depends on the search flags: for file list entries you just get the base name unless SEARCH_FILES is set, for checksums you get an empty string unless SEARCH_CHECKSUMS is set. Numeric values are currently stringified to an empty string. That's just how it is. 💀
my $str = $d->str;
str = str(d)
str = d.to_s

THE SELECTION CLASS

Okay so selections are the easiest way to deal with sets of packages. Slay. There's a whole bunch of constructors to build them, but the most useful one is probably the select() method over on the Pool class. Start there. ✨

CONSTANTS

  • SELECTION_NAME — build the selection by matching package names.
  • SELECTION_PROVIDES — build the selection by matching package provides.
  • SELECTION_FILELIST — build the selection by matching package files.
  • SELECTION_CANON — build the selection by matching the canonical representation of the package. Normally that's a combo of the name, the version, and the arch. The whole lewk.
  • SELECTION_DOTARCH — allow an ".<architecture>" suffix when matching names or provides.
  • SELECTION_REL — allow a relation to be specified when matching names or dependencies, like "name >= 1.2". Very "give me exactly this" energy.
  • SELECTION_GLOB — allow glob matching for package names, package provides, and file names.
  • SELECTION_NOCASE — ignore case when matching package names, package provides, and file names.
  • SELECTION_FLAT — return only one selection element describing the selected packages. The default is to make multiple elements for all globbed packages. And bestie, multiple elements are actually useful when you wanna turn the selection into an install job, because in that case you want an install job for every single globbed package. Facts.
  • SELECTION_SKIP_KIND — strip a "packagekind:" prefix off the package names.
  • SELECTION_MATCH_DEPSTR — when matching dependencies, do a string match on the result of dep2str instead of running the normal dependency intersect algorithm.
  • SELECTION_INSTALLED_ONLY — limit the package search to installed packages only.
  • SELECTION_SOURCE_ONLY — limit the package search to source packages only.
  • SELECTION_WITH_SOURCE — extend the search so it also matches source packages. Default is binary packages only, fyi.
  • SELECTION_WITH_DISABLED — extend the search to also include disabled packages.
  • SELECTION_WITH_BADARCH — extend the search to also include packages that aren't installable on the configured architecture.
  • SELECTION_WITH_ALL — shortcut for selecting those three modifiers above. Efficient queen. 👑
  • SELECTION_ADD — add the match result to the current selection instead of replacing it.
  • SELECTION_SUBTRACT — remove the match result from the current selection instead of replacing it.
  • SELECTION_FILTER — intersect the match result with the current selection instead of replacing it.

ATTRIBUTES

  • Pool *pool; (read only) — back pointer to the pool.
$d->{pool}
d.pool
d.pool
  • int flags; (read only) — the result flags of the selection. These are a subset of the flags you used when creating it, and they tell you which method actually produced the result. Example: create the selection with “SELECTION_NAME | SELECTION_PROVIDES” and the resulting flags will be either SELECTION_NAME or SELECTION_PROVIDES, depending on whether a package matched the name or not. And if nothing matched at all, the flags are zero. Zero. Nothing. Dust. 💀
$sel->{flags}
flags = sel.flags
flags = sel.flags

METHODS

  • bool isempty() — returns true if the selection is empty, meaning no package could be matched. Sad but honest.
$sel->isempty()
sel.isempty()
sel.isempty?
  • Selection clone(int flags = 0) — gives you a copy of a selection. Dupe it, it's yours.
my $cloned = $sel->clone();
cloned = sel.clone()
cloned = sel.clone()
  • void filter(Selection *other) — intersect two selections. A package only stays in the selection if it's also in the other selection. This one modifies in place, so watch it. 🫣
$sel->filter($other);
sel.filter(other)
sel.filter(other)
  • void add(Selection *other) — build the union of two selections. Every package in the other selection gets poured into this selection object. Also in place. And lowkey important: the selection flags are no longer meaningful after an add operation.
$sel->add($other);
sel.add(other)
sel.add(other)
  • void subtract(Selection *other) — remove the packages of the other selection from this selection's packages. In place, baby.
$sel->subtract($other);
sel.subtract(other)
sel.subtract(other)
  • void add_raw(Id how, Id what) — add a raw element to the selection. Go check the Job class for what how and what actually mean. Same warning as before: the selection flags stop being meaningful after an add_raw operation.
$sel->add_raw($how, $what);
sel.add_raw(how, what)
sel.add_raw(how, what)
  • Job *jobs(int action) — convert a selection into an array of Job objects. The action parameter gets or-ed into the “how” part of the job, and it describes what kind of job it is (install, erase, that whole family). For the action and action modifier constants, the Job class is right there. 📋
my @jobs = $sel->jobs($action);
jobs = sel.jobs(action)
jobs = sel.jobs(action)
  • Solvable *solvables() — convert a selection into an array of Solvable objects. Glow up from selection → solvables. 🌈
my @solvables = $sel->solvables();
solvables = sel.solvables()
solvables = sel.solvables()
  • void select(const char *name, int flags) — do a select operation and combine the result with the current selection. You pick the combination method with SELECTION_ADD, SELECTION_SUBTRACT, or SELECTION_FILTER. If you use none of them, SELECTION_FILTER|SELECTION_WITH_ALL is assumed. Surprise! That's the default. 💅
$sel->select($name, $flags);
sel.select(name, flags)
sel.select(name, flags)
  • void matchdeps(const char *name, int flags, Id keyname, Id marker = -1) — do a matchdeps operation and combine the result with the current selection. Same combine energy as above.
$sel->matchdeps($name, $flags, $keyname);
sel.matchdeps(name, flags, keyname)
sel.matchdeps(name, flags, keyname)
  • void matchdepid(DepId dep, int flags, Id keyname, Id marker = -1) — do a matchdepid operation and combine the result with the current selection.
$sel->matchdepid($dep, $flags, $keyname);
sel.matchdepid(dep, flags, keyname)
sel.matchdepid(dep, flags, keyname)
  • void matchsolvable(Solvable solvable, int flags, Id keyname, Id marker = -1) — do a matchsolvable operation and combine the result with the current selection. Last of the trio bestie 🫶
$sel->matchsolvable($solvable, $flags, $keyname);
sel.matchsolvable(solvable, flags, keyname)
sel.matchsolvable(solvable, flags, keyname)
  • <stringification> — returns a string describing the selection. For when you just need to look at it. 🎀
my $str = $sel->str;
str = str(sel)
str = sel.to_s

✨ THE JOB CLASS ✨

Okay bestie, so jobs are literally the way you tell the dependency solver what to do. Most of the time jobs get created by calling the jobs() method on a Selection object, but there's also a Job() constructor chillin' in the Pool class. 💅

💖 CONSTANTS 💖

Selection constants:

  • SOLVER_SOLVABLE — the “what” part is the id of a solvable. 🔥
  • SOLVER_SOLVABLE_NAME — the “what” part is the id of a package name. 🎀
  • SOLVER_SOLVABLE_PROVIDES — the “what” part is the id of a package provides. ✨
  • SOLVER_SOLVABLE_ONE_OF — the “what” part is an offset into the “whatprovides” data, created by calling the towhatprovides() pool method. 🦋
  • SOLVER_SOLVABLE_REPO — the “what” part is the id of a repository. 💖
  • SOLVER_SOLVABLE_ALL — the “what” part is ignored, all packages are selected. 👑
  • SOLVER_SOLVABLE_SELECTMASK — a mask containing all the above selection bits. 🌈

Action constants:

  • SOLVER_NOOP — do nothing. 💀
  • SOLVER_INSTALL — install a package of the specified set of packages. It tries to install the best matching package (i.e. the highest version of the packages from the repositories with the highest priority). 🔥
  • SOLVER_ERASE — erase all of the packages from the specified set. If a package is not installed, erasing it will keep it from getting installed. 🧚
  • SOLVER_UPDATE — update the matching installed packages to their best version. If none of the specified packages are installed, try to update the installed packages to the specified versions. See the section about targeted updates for more info. 💅
  • SOLVER_WEAKENDEPS — allow one to break the dependencies of the matching packages. Handle with care. 😭
  • SOLVER_MULTIVERSION — mark the matched packages for multiversion install. If they get to be installed because of some other job, the installation will keep the old version of the package installed (for rpm this is done by using -i instead of -U). 🎀
  • SOLVER_LOCK — do not change the state of the matched packages, i.e. when they are installed they stay installed, if not they are not selected for installation. 🔒
  • SOLVER_DISTUPGRADE — update the matching installed packages to the best version included in one of the repositories. After this operation, all come from one of the available repositories except orphaned packages. Orphaned packages are packages that have no relation to the packages in the repositories, i.e. no package in the repositories have the same name or obsolete the orphaned package. This action brings the installed packages in sync with the ones in the repository. By default it also turns off arch/vendor/version locking for the affected packages to simulate a fresh installation. This means that distupgrade can actually downgrade packages if only lower versions of a package are available in the repositories. You can tweak this behavior with the SOLVER_FLAG_DUP_ solver flags. 🌟
  • SOLVER_DROP_ORPHANED — erase all the matching installed packages if they are orphaned. This only makes sense if there is a “distupgrade all packages” job. The default is to erase orphaned packages only if they block the installation of other packages. 🗑️
  • SOLVER_VERIFY — fix dependency problems of matching installed packages. The default is to ignore dependency problems for installed packages. 🔍
  • SOLVER_USERINSTALLED — the matching installed packages are considered to be installed by a user, thus not installed to fulfill some dependency. This is needed input for the calculation of unneeded packages for jobs that have the SOLVER_CLEANDEPS flag set. 🫶
  • SOLVER_ALLOWUNINSTALL — allow the solver to deinstall the matching installed packages if they get into the way of resolving a dependency. This is like the SOLVER_FLAG_ALLOW_UNINSTALL flag, but limited to a specific set of packages. ⚠️
  • SOLVER_FAVOR — prefer the specified packages if the solver encounters an alternative. If a job contains multiple matching favor/disfavor elements, the last one takes precedence. 💖
  • SOLVER_DISFAVOR — avoid the specified packages if the solver encounters an alternative. This can also be used to block recommended or supplemented packages from being installed. 🚫
  • SOLVER_EXCLUDEFROMWEAK — avoid the specified packages to satisfy recommended or supplemented dependencies. Unlike SOLVER_DISFAVOR, it does not interfere with other rules. 🧚
  • SOLVER_JOBMASK — a mask containing all the above action bits. 🌈

Action modifier constants:

  • SOLVER_WEAK — makes the job a weak job. The solver tries to fulfill weak jobs, but does not report a problem if it is not possible to do so. 🫶
  • SOLVER_ESSENTIAL — makes the job an essential job. If there is a problem with the job, the solver will not propose to remove the job as one solution (unless all other solutions are also to remove essential jobs). 👑
  • SOLVER_CLEANDEPS — the solver will try to also erase all packages dragged in through dependencies when erasing the package. This needs SOLVER_USERINSTALLED jobs to maximize user satisfaction. ✨
  • SOLVER_FORCEBEST — insist on the best package for install, update, and distupgrade jobs. If this flag is not used, the solver will use the second-best package if the best package cannot be installed for some reason. When this flag is used, the solver will generate a problem instead. 🔥
  • SOLVER_TARGETED — forces targeted operation update and distupgrade jobs. See the section about targeted updates for more info. 🎯

Set constants.

  • SOLVER_SETEV — the job specified the exact epoch and version of the package set. 💅
  • SOLVER_SETEVR — the job specified the exact epoch, version, and release of the package set. 🎀
  • SOLVER_SETARCH — the job specified the exact architecture of the packages from the set. 🏗️
  • SOLVER_SETVENDOR — the job specified the exact vendor of the packages from the set. 🏢
  • SOLVER_SETREPO — the job specified the exact repository of the packages from the set. 📦
  • SOLVER_SETNAME — the job specified the exact name of the packages from the set. 🏷️
  • SOLVER_NOAUTOSET — turn off automatic set flag generation for SOLVER_SOLVABLE jobs. 🚫
  • SOLVER_SETMASK — a mask containing all the above set bits. 🌈

See the section about set bits for more information.

📦 ATTRIBUTES 📦

pool — read only.

Pool *pool;                             /* read only */
$job->{pool}
d.pool
d.pool

Back pointer to pool. 💅

how — read/write.

Id how;                                 /* read/write */
$job->{how}
d.how
d.how

Union of the selection, action, action modifier, and set flags. The selection part describes the semantics of the “what” Id. 🎀

what — read/write.

Id what;                                /* read/write */
$job->{what}
d.what
d.what

Id describing the set of packages, the meaning depends on the selection part of the “how” attribute. ✨

🛠️ METHODS 🛠️

solvables()

Solvable *solvables()
my @solvables = $job->solvables();
solvables = job.solvables()
solvables = job.solvables()

Return the set of solvables of the job as an array of Solvable objects. 🔥

isemptyupdate()

bool isemptyupdate()
$job->isemptyupdate()
job.isemptyupdate()
job.isemptyupdate?

Convenience function to find out if the job describes an update job with no matching packages, i.e. a job that does nothing. Some package managers like “zypper” like to turn those jobs into install jobs, i.e. an update of a not-installed package will result into the installation of the package. 🫶

<stringification>

my $str = $job->str;
str = str(job)
str = job.to_s

Return a string describing the job. 💬

<equality>

if ($job1 == $job2)
if job1 == job2:
if job1 == job2

Two jobs are equal if they belong to the same pool and both the “how” and the “what” attributes are the same. ✨

🎯 TARGETED UPDATES 🎯

Libsolv has two modes for upgrades and distupgrade: targeted and untargeted. Untargeted mode means that the installed packages from the specified set will be updated to the best version. Targeted means that packages that can be updated to a package in the specified set will be updated to the best package of the set.

Here’s an example to explain the subtle difference. Suppose that you have package A installed in version 1.1, A-1.2 is available in one of the repositories and there is also package B that obsoletes package A.

  • An untargeted update of A will update the installed A-1.1 to package B, because that is the newest version (B obsoletes A and is thus newer). 💀
  • A targeted update of A will update A-1.1 to A-1.2, as the set of packages contains both A-1.1 and A-1.2, and A-1.2 is the newer one. 🎯
  • An untargeted update of B will do nothing, as B is not installed. 🙈
  • A targeted update of B will update A-1.1 to B. 🔥

Note that the default is to do “auto-targeting”, thus if the specified set of packages does not include an installed package, the solver will assume targeted operation even if SOLVER_TARGETED is not used.

This mostly matches the intent of the user, with one exception: in the example above, an update of A-1.2 will update A-1.1 to A-1.2 (targeted mode), but a second update of A-1.2 will suddenly update to B, as untargeted mode is chosen because A-1.2 is now installed. 😭

If you want to have full control over when targeting mode is chosen, turn off auto-targeting with the SOLVER_FLAG_NO_AUTOTARGET solver option. In that case, all updates are considered to be untargeted unless they include the SOLVER_TARGETED flag. 💅

🔧 SET BITS 🔧

Set bits specify which parts of the specified packages were specified by the user. It is used by the solver when checking if an operation is allowed or not. For example, the solver will normally not allow the downgrade of an installed package. But it will not report a problem if the SOLVER_SETEVR flag is used, as it then assumes that the user specified the exact version and thus knows what he is doing. 🧠

So if a package screen-1-1 is installed for the x86_64 architecture and version 2-1 is only available for the i586 architecture, installing package screen-2.1 will ask the user for confirmation because of the different architecture. When using the Selection class to create jobs the set bits are automatically added, e.g. selecting “screen.i586” will automatically add SOLVER_SETARCH, and thus no problem will be reported. 🌈

💖 THE SOLVER CLASS 💖

okay so bestie, dependency solving is literally THE whole point of this library, it's the moment, the main character, the reason we're all here. 🫶 you need a solver object so there's somewhere to store the result of the solver run, and here's the iconic part: you can reuse that same solver object for multiple jobs, and reusing it lets the solver re-use the dependency rules it already computed. efficiency queen behavior, no cap. ✨

🌸 CONSTANTS 🌸

Flags to modify some of the solver's behavior — tiny little switches that change the whole vibe, so pay attention 👑

  • SOLVER_FLAG_ALLOW_DOWNGRADE — lets the solver downgrade packages without asking for confirmation (aka without reporting a problem first). 🫣
  • SOLVER_FLAG_ALLOW_ARCHCHANGE — lets the solver change the architecture of an installed package without asking for confirmation. Note that changes to/from noarch are always considered to be allowed, so those ones don't even need this flag, periodt.
  • SOLVER_FLAG_ALLOW_VENDORCHANGE — lets the solver change the vendor of an installed package without asking for confirmation. here's the lore: each vendor is part of one or more vendor equivalence classes, and normally installed packages may only change their vendor if the new vendor shares at least one equivalence class. 👯
  • SOLVER_FLAG_ALLOW_NAMECHANGE — lets the solver change the name of an installed package, i.e. install a package with a different name that obsoletes the installed package. this one is on by default 💅
  • SOLVER_FLAG_ALLOW_UNINSTALL — lets the solver erase installed packages to fulfill the jobs. this flag also includes the above flags, it's an all-inclusive moment. you may want to set this flag if you only have SOLVER_ERASE jobs, because in that case it's better for the user to check the transaction overview instead of approving every single package that needs to be erased. way less annoying, fr fr.
  • SOLVER_FLAG_DUP_ALLOW_DOWNGRADE — like SOLVER_FLAG_ALLOW_DOWNGRADE, but used in distupgrade mode. same energy, different mode 🦋
  • SOLVER_FLAG_DUP_ALLOW_ARCHCHANGE — like SOLVER_FLAG_ALLOW_ARCHCHANGE, but used in distupgrade mode.
  • SOLVER_FLAG_DUP_ALLOW_VENDORCHANGE — like SOLVER_FLAG_ALLOW_VENDORCHANGE, but used in distupgrade mode.
  • SOLVER_FLAG_DUP_ALLOW_NAMECHANGE — like SOLVER_FLAG_ALLOW_NAMECHANGE, but used in distupgrade mode.
  • SOLVER_FLAG_NO_UPDATEPROVIDE — so if multiple packages obsolete an installed package, the solver checks the provides of every such package and ignores all packages that do not provide the installed package name. meaning: you can have an official update candidate that provides the old name, and other packages that also obsolete it but are just... not considered for updating. iconic separation. if you can't use this feature, you can turn it off by setting this flag. 🔥
  • SOLVER_FLAG_NEED_UPDATEPROVIDE — somewhat the opposite of SOLVER_FLAG_NO_UPDATEPROVIDE: only packages that provide the installed package names are considered for updating.
  • SOLVER_FLAG_SPLITPROVIDES — makes the solver aware of special provides of the form <packagename>:<path> used in SUSE systems to support package splits. iykyk 🧚
  • SOLVER_FLAG_IGNORE_RECOMMENDED — do not process optional (aka weak) dependencies. ignoring them, respectfully. 🙈
  • SOLVER_FLAG_STRONG_RECOMMENDS — makes the solver backtrack to satisfy Recommends dependencies (e.g., update packages, choose different alternatives, etc.). with this flag, Recommends function like Requires, which can be broken. you can use this feature to allow the solver to install weak dependencies, even if it requires updating currently installed packages. it's giving ✨aggressive✨.
  • SOLVER_FLAG_ADD_ALREADY_RECOMMENDED — install recommended or supplemented packages even if they have no connection to the current transaction. you can use this feature to implement a simple way for the user to install new recommended packages that were not available in the past. throwback installs, we love to see it 💖
  • SOLVER_FLAG_NO_INFARCHCHECK — turns off the inferior architecture checking that is normally done by the solver. normally the solver allows only the installation of packages from the "best" architecture if a package is available for multiple architectures. so this flag is like, "bestie we're not doing the ranking today" ✋
  • SOLVER_FLAG_BEST_OBEY_POLICY — makes the SOLVER_FORCEBEST job option consider only packages that meet the policies for installed packages, i.e. no downgrades, no architecture change, no vendor change (see the first flags of this section 👆). if the flag is not specified, the solver will enforce the installation of the best package ignoring the installed packages, which may conflict with the set policy. messy. so messy. 😭
  • SOLVER_FLAG_NO_AUTOTARGET — do not enable auto-targeting up update and distupgrade jobs. see the section on targeted updates for more information. 📖
  • SOLVER_FLAG_KEEP_ORPHANS — do not allow orphaned packages to be deinstalled if they get in the way of resolving other packages. protecting the strays 🥺
  • SOLVER_FLAG_BREAK_ORPHANS — ignore dependencies of orphaned packages that get in the way of resolving non-orphaned ones. > ⚠️ setting this flag might result in no longer working packages in case they are orphaned. so like... yes but at what cost.
  • SOLVER_FLAG_FOCUS_INSTALLED — resolve installed packages before resolving the given jobs. setting this flag means the solver will prefer picking a package version that fits the other installed packages over updating installed packages. loyalty to the ones already here 🫶
  • SOLVER_FLAG_FOCUS_BEST — first resolve the given jobs, then the dependencies of the resulting packages, then resolve all already installed packages. this will result in more packages being updated than when the flag is not used. go big.
  • SOLVER_FLAG_FOCUS_NEW — first resolve the given jobs, then the dependencies of the resulting packages while ignoring the ones provided by currently installed packages. after that, resolve all already installed packages. this is similar to SOLVER_FLAG_FOCUS_BEST but less aggressive about updating packages. soft launch energy 🌸
  • SOLVER_FLAG_INSTALL_ALSO_UPDATES — update the package if a job is already fulfilled by an installed package. like, "oh it's done? cool, updating anyway 💅"
  • SOLVER_FLAG_YUM_OBSOLETES — turns on yum-like package split handling. see the yum documentation for more details.
  • SOLVER_FLAG_URPM_REORDER — turns on urpm-like package reordering for kernel packages. see the urpm documentation for more details.

🔮 Basic rule types 🔮

  • SOLVER_RULE_UNKNOWN — a rule of an unknown class. you should never encounter those. if you do... good luck bestie 💀
  • SOLVER_RULE_PKG — a rule generated because of a package dependency.
  • SOLVER_RULE_UPDATE — a rule to implement the update policy of installed packages. every installed package has an update rule that consists of the packages that may replace the installed package.
  • SOLVER_RULE_FEATURE — feature rules are fallback rules used when an update rule is disabled. they include all packages that may replace the installed package ignoring the update policy, i.e. they contain downgrades, arch changes and so on. without them, the solver would simply erase installed packages if their update rule gets disabled. drama. 😳
  • SOLVER_RULE_JOB — job rules implement the job given to the solver.
  • SOLVER_RULE_DISTUPGRADE — these are simple negative assertions that make sure that only packages are kept that are also available in one of the repositories.
  • SOLVER_RULE_INFARCH — infarch rules are also negative assertions, they disallow the installation of packages when there are packages of the same name but with a better architecture. not on my watch ✋
  • SOLVER_RULE_CHOICE — choice rules are used to make sure that the solver prefers updating to installing different packages when some dependency is provided by multiple packages with different names. the solver may always break choice rules, so you will not see them when a problem is found. sneaky 👀
  • SOLVER_RULE_LEARNT — these rules are generated by the solver to keep it from running into the same problem multiple times when it has to backtrack. they are the main reason why a sat solver is faster than other dependency solver implementations. ⭐ learned the lesson once, never again.

🎀 Special dependency rule types 🎀

  • SOLVER_RULE_PKG_NOT_INSTALLABLE — this rule was added to prevent the installation of a package of an architecture that does not work on the system.
  • SOLVER_RULE_PKG_NOTHING_PROVIDES_DEP — the package contains a required dependency which was not provided by any package. nobody stepped up 😭
  • SOLVER_RULE_PKG_REQUIRES — the package contains a required dependency which was provided by at least one package. phew 🫶
  • SOLVER_RULE_PKG_SELF_CONFLICT — the package conflicts with itself. this is not allowed by older rpm versions. ma'am, that's you. 🙈
  • SOLVER_RULE_PKG_CONFLICTS — the package conflicts with some other package. enemies to enemies arc.
  • SOLVER_RULE_PKG_SAME_NAME — this rules make sure that only one version of a package is installed in the system. one version only, this is not a polycule 💅
  • SOLVER_RULE_PKG_OBSOLETES — to fulfill the dependencies two packages need to be installed, but one of the packages obsoletes the other one. awkward.
  • SOLVER_RULE_PKG_IMPLICIT_OBSOLETES — to fulfill the dependencies two packages need to be installed, but one of the packages has provides a dependency that is obsoleted by the other one. see the POOL_FLAG_IMPLICITOBSOLETEUSESPROVIDES flag.
  • SOLVER_RULE_PKG_INSTALLED_OBSOLETES — to fulfill the dependencies a package needs to be installed that is obsoleted by an installed package. see the POOL_FLAG_NOINSTALLEDOBSOLETES flag.
  • SOLVER_RULE_PKG_RECOMMENDS — the package contains a recommended dependency.
  • SOLVER_RULE_PKG_SUPPLEMENTS — the package contains a dependency to specify it supplements another package.
  • SOLVER_RULE_PKG_CONSTRAINS — the package contains a constraint against some other package (disttype conda).
  • SOLVER_RULE_JOB_NOTHING_PROVIDES_DEP — the user asked for installation of a package providing a specific dependency, but no available package provides it. rude honestly.
  • SOLVER_RULE_JOB_UNKNOWN_PACKAGE — the user asked for installation of a package with a specific name, but no available package has that name. who? never heard of her. 💀
  • SOLVER_RULE_JOB_PROVIDED_BY_SYSTEM — the user asked for the erasure of a dependency that is provided by the system (i.e. for special hardware or language dependencies), and this cannot be done with a job. blocked bestie 🚫
  • SOLVER_RULE_JOB_UNSUPPORTED — the user asked for something that is not yet implemented, e.g. the installation of all packages at once. it's giving "coming soon" 🌈

🌟 Policy error constants 🌟

  • POLICY_ILLEGAL_DOWNGRADE — the solver ask for permission before downgrading packages. consent first, always 💅
  • POLICY_ILLEGAL_ARCHCHANGE — the solver ask for permission before changing the architecture of installed packages.
  • POLICY_ILLEGAL_VENDORCHANGE — the solver ask for permission before changing the vendor of installed packages.
  • POLICY_ILLEGAL_NAMECHANGE — the solver stops and asks your permission first before it swaps out an installed package for a package that has a totally different name. consent is key bestie 💅

Solution element type constants 🧩

  • SOLVER_SOLUTION_JOB — this problem can be fixed by removing the specified job.
  • SOLVER_SOLUTION_POOLJOB — this problem can be fixed by removing the specified job that's defined in the pool.
  • SOLVER_SOLUTION_INFARCH — this problem can be fixed by letting the specified package install with an inferior architecture.
  • SOLVER_SOLUTION_DISTUPGRADE — this problem can be fixed by letting the specified package stay installed.
  • SOLVER_SOLUTION_BEST — this problem can be fixed by letting the specified package install even though it's not the best available package.
  • SOLVER_SOLUTION_ERASE — this problem can be fixed by letting the specified package get erased.
  • SOLVER_SOLUTION_REPLACE — this problem can be fixed by letting the package get replaced with some other package.
  • SOLVER_SOLUTION_REPLACE_DOWNGRADE — this problem can be fixed by letting the package get replaced with some other package that has a lower version.
  • SOLVER_SOLUTION_REPLACE_ARCHCHANGE — this problem can be fixed by letting the package get replaced with some other package that has a different architecture.
  • SOLVER_SOLUTION_REPLACE_VENDORCHANGE — this problem can be fixed by letting the package get replaced with some other package that has a different vendor.
  • SOLVER_SOLUTION_REPLACE_NAMECHANGE — this problem can be fixed by letting the package get replaced with some other package that has a different name.

Reason constants 🕵️‍♀️

  • SOLVER_REASON_UNRELATED — the package status didn't change, because it wasn't related to any job.
  • SOLVER_REASON_UNIT_RULE — the package was installed/erased/kept because of a unit rule, i.e. a rule where all literals but one were false.
  • SOLVER_REASON_KEEP_INSTALLED — the package was chosen while trying to keep as many packages installed as possible.
  • SOLVER_REASON_RESOLVE_JOB — the decision happened to fulfill a job rule.
  • SOLVER_REASON_UPDATE_INSTALLED — the decision happened to fulfill a package update request.
  • SOLVER_REASON_CLEANDEPS_ERASE — the package was erased when cleaning up dependencies from other erased packages.
  • SOLVER_REASON_RESOLVE — the package was installed to fulfill package dependencies.
  • SOLVER_REASON_WEAKDEP — the package was installed because of a weak dependency (Recommends or Supplements).
  • SOLVER_REASON_RESOLVE_ORPHAN — the decision about the package was made while deciding the fate of orphaned packages.
  • SOLVER_REASON_RECOMMENDED — this is a special case of SOLVER_REASON_WEAKDEP.
  • SOLVER_REASON_SUPPLEMENTED — this is a special case of SOLVER_REASON_WEAKDEP.
  • SOLVER_REASON_UNSOLVABLE — this is a special case where a rule cannot be fulfilled.
  • SOLVER_REASON_PREMISE — this is a special case for the premises of learnt rules.

ATTRIBUTES 💖

  • pool pointer
Pool *pool;                             /* read only */
$job->{pool}
d.pool
d.pool

A back pointer to the pool, bestie. that's the whole vibe.

METHODS ✨

  • int set_flag(int flag, int value)
int set_flag(int flag, int value)
my $oldvalue = $solver->set_flag($flag, $value);
oldvalue = solver.set_flag(flag, value)
oldvalue = solver.set_flag(flag, value)
  • int get_flag(int flag)
int get_flag(int flag)
my $value = $solver->get_flag($flag);
value = solver.get_flag(flag)
value = solver.get_flag(flag)

So these two are the set/get duo for a solver specific flag. The flags define the policies the solver has to obey, and they're explained over in the CONSTANTS section of this class — go read it, iykyk. 👑

  • Problem *solve(Job *jobs)
Problem *solve(Job *jobs)
my @problems = $solver->solve(\@jobs);
problems = solver.solve(jobs)
problems = solver.solve(jobs)

Solve a problem specified in the job list (plus the jobs defined in the pool). You get back an array of problems that need user interaction, or an empty array if no problems were encountered. Wanna know how to deal with problems? The Problem class has you covered.

  • Transaction transaction()
Transaction transaction()
my $trans = $solver->transaction();
trans = solver.transaction()
trans = solver.transaction()

Returns the transaction you use to actually implement the calculated package changes. Fun fact: a transaction is available even if problems were found, which is super useful for interactive user interfaces that show both the job result and the problems at the same time. slay 🫶

  • Solvable *get_recommended(bool noselected=0)
Solvable *get_recommended(bool noselected=0)
my @solvables = $solver->get_recommended();
solvables = solver.get_recommended()
solvables = solver.get_recommended()

Returns all solvables that are recommended by the solver run result. Heads up: this includes solvables included in the result, so set noselected if you want to filter those out.

  • Solvable *get_suggested(bool noselected=0)
Solvable *get_suggested(bool noselected=0)
my @solvables = $solver->get_suggested();
solvables = solver.get_suggested()
solvables = solver.get_suggested()

Returns all solvables that are suggested by the solver run result. Same deal as above: this includes solvables included in the result, so set noselected if you want to filter those.

  • Decision = get_decision(Solvable *s)
Decision = get_decision(Solvable *s)
my $decision = $solver->get_decision($solvable);
decision = solver.get_decision(solvable);
decision = solver.get_decision(solvable);

Returns a decision object that describes why a specific solvable was installed or erased. See the Decision class for more information.

  • Decision *get_decisionlist(Solvable *s)
Decision *get_decisionlist(Solvable *s)
my @decisions = $solver->get_decisionlist($solvable);
decisions = solver.get_decisionlist(solvable)
decisions = solver.get_decisionlist(solvable)

Returns a list of decisions that caused the specific solvable to be installed or erased. ngl this is usually more useful than the get_decision() method, because it hands you every involved decision instead of just a single one. 🎀

  • Alternative *alternatives()
Alternative *alternatives()
my @alternatives = $solver->alternatives();
alternatives = solver.alternatives()
alternatives = solver.alternatives()

Returns all alternatives recorded in the solver run. See the Alternative class for more information.

  • int alternatives_count()
int alternatives_count()
my $cnt = $solver->alternatives_count();
cnt = solver.alternatives_count()
cnt = solver.alternatives_count()

Returns the number of alternatives without creating alternative objects. efficiency queen 💅

THE PROBLEM CLASS 😭

Problems are the way the solver interacts with you, the user. You can just list all the problems and terminate your program, but the way better move is to present the solutions to the user and let them pick the ones they like. let them cook.

ATTRIBUTES 🌸

  • solver pointer
Solver *solv;                           /* read only */
$problem->{solv}
problem.solv
problem.solv

A back pointer to the solver object.

  • id
Id id;                                  /* read only */
$problem->{id}
problem.id
problem.id

The Id of the problem. The first problem has Id 1, and they're numbered consecutively from there. counting is hard, we know. 💀

METHODS 🦋

  • Rule findproblemrule()
Rule findproblemrule()
my $probrule = $problem->findproblemrule();
probrule = problem.findproblemrule()
probrule = problem.findproblemrule()

Returns the rule that caused the problem. Okay so of course in most situations there is no single responsible rule — it's like, many rules that interconnect with each other that created the problem. But regardless, the solver uses some heuristic approach to find a rule that somewhat describes the problem best to the user. bestie it's doing its best.

  • Rule *findallproblemrules(bool unfiltered = 0)
Rule *findallproblemrules(bool unfiltered = 0)
my @probrules = $problem->findallproblemrules();
probrules = problem.findallproblemrules()
probrules = problem.findallproblemrules()

Returns all rules responsible for the problem. The returned set of rules contains all the needed information about why there was a problem, but ngl it's hard to present them to the user in a sensible way. By default all update and job rules get filtered out (unless the returned rules only consist of those types, in which case, well 😭).

  • Decision *get_decisionlist()
Decision *get_decisionlist()
my @decisions = $problem->get_decisionlist();
decisions = problem.get_decisionlist()
decisions = problem.get_decisionlist()

Returns a list of decisions proving the problem. This is somewhat similar to findallproblemrules(), but the output comes in an order that makes it easier to understand why the solver could not find a solution. ✨

  • Decisionset *get_decisionsetlist()
Decisionset *get_decisionsetlist()
my @decisionsets = $problem->get_decisionsetlist();
decisionsets = problem.get_decisionsetlist()
decisionsets = problem.get_decisionsetlist()

Like the get_decisionlist() method, but the decisions are merged into individual sets.

  • Rule *get_learnt()
Rule *get_learnt()
my @learnt = $problem->get_learnt();
learnt = problem.get_learnt()
learnt = problem.get_lerant()

Returns a list of learnt rules that are part of the problem proof. This is useful for presenting a complete proof to the user. (and yes bestie, the get_lerant() typo is real, it's canon, we do not touch it 🙈)

  • Solution *solutions()
Solution *solutions()
my @solutions = $problem->solutions();
solutions = problem.solutions()
solutions = problem.solutions()

Returns an array containing multiple possible solutions to fix the problem. See the Solution class for more information.

  • int solution_count()
int solution_count()
my $cnt = $problem->solution_count();
cnt = problem.solution_count()
cnt = problem.solution_count()

Returns the number of solutions without creating solution objects.

  • <stringification>
<stringification>
my $str = $problem->str;
str = str(problem)
str = problem.to_s

Returns a string describing the problem. This is a convenience function — basically a shorthand for calling findproblemrule(), then ruleinfo() on the problem rule, and problemstr() on the ruleinfo object. three steps, one lil method, iconic. 👑

💅 THE RULE CLASS ✨

okay so rules? rules are literally the basic block of sat solving, bestie. every single package dependency gets translated into one rule, or honestly sometimes a whole lil' squad of rules. it's giving "one text, many receipts" 🧾💖

🎀 ATTRIBUTES 🎀

  • Solver *solv; /* read only */ — $rule->{solv}, rule.solv, rule.solv. back pointer to the solver object. that's the "who do i belong to" link 🫶
  • Id id; /* read only */ — $rule->{id}, rule.id, rule.id. the id of the rule. it's their name tag, okay ✨
  • int type; /* read only */ — $rule->{type}, rule.type, rule.type. the basic type of the rule. 🦋 for the type list, go look at the constant section of the solver class, it's all there i promise.

💫 METHODS 💫

Ruleinfo info()
my $ruleinfo = $rule->info();
ruleinfo = rule.info()
ruleinfo = rule.info()

returns a Ruleinfo object that has the tea on why this rule got created. but — and this is the important part — go read the allinfos() method below before you get too comfy 👀

Ruleinfo *allinfos()
my @ruleinfos = $rule->allinfos();
ruleinfos = rule.allinfos()
ruleinfos = rule.allinfos()

so bestie, the same dependency rule can get created because of multiple dependencies. one Ruleinfo is simply not enough to describe all the reasons — it's giving group project energy 😭. so allinfos() hands you back an array of all the infos about a rule. every reason, every time 💚

Decision *get_decisionlist()
my @decisions = $rule->get_decisionlist();
decisions = rule.get_decisionlist()
decisions = rule.get_decisionlist()

returns a list of decisions that prove a learnt rule. the receipts, if you will 🧚

Decision *get_decisionsetlist()
my @decisionsets = $rule->get_decisionsetlist();
decisionsets = rule.get_decisionsetlist()
decisionsets = rule.get_decisionsetlist()

same vibe as get_decisionlist(), except the decisions get merged into individual sets instead. grouping the girlies together 💅

Rule *get_learnt()
my @learnt = $rule->get_learnt();
learnt = rule.get_learnt()
learnt = rule.get_lerant()

returns a list of learnt rules that are part of the learnt rule proof. (and yes, that last line is written exactly like that on the page, get_lerant(), i'm just transcribing it faithfully 🙈 not my circus, not my monkeys)

<equality>

if ($rule1 == $rule2)
if rule1 == rule2:
if rule1 == rule2

two rules are equal if they belong to the same solver and have the same id. that's the whole rule. periodt. 💅

🌈 THE RULEINFO CLASS 🌈

a Ruleinfo describes one reason why a rule was created. one. singular. because apparently one rule deserves a whole committee of explanations 😌

🎀 ATTRIBUTES 🎀

  • Solver *solv; /* read only */ — $ruleinfo->{solv}, ruleinfo.solv, ruleinfo.solv. back pointer to the solver object. yes, again, everyone has one 🫶
  • int type; /* read only */ — $ruleinfo->{type}, ruleinfo.type, ruleinfo.type. the type of the ruleinfo. for this one you need the constant section of the solver class — both the rule type list and the special type list. two lists, bestie, go look 🔥
  • Dep *dep; /* read only */ — $ruleinfo->{dep}, ruleinfo.dep, ruleinfo.dep. the dependency that led to the creation of the rule. the origin story ✨
  • Dep *dep_id; /* read only */ — $ruleinfo->{dep_id}, ruleinfo.dep_id, ruleinfo.dep_id. the Id of the dependency leading to the creation of the rule — or zero if there isn't one. zero is the "no thoughts head empty" value here 🍓
  • Solvable *solvable; /* read only */ — $ruleinfo->{solvable}, ruleinfo.solvable, ruleinfo.solvable. the involved Solvable, like for example the one containing the dependency 💚
  • Solvable *othersolvable; /* read only */ — $ruleinfo->{othersolvable}, ruleinfo.othersolvable, ruleinfo.othersolvable. the other involved Solvable, if there is one — like the one providing the dependency 🍑

okay so the source page doesn't slap a METHODS heading on these next ones, we just keep it moving, i got you 🫡

const char *problemstr();

my $str = $ruleinfo->problemstr();
str = ruleinfo.problemstr()
str = ruleinfo.problemstr()

a string describing the ruleinfo from a problem perspective. word of warning bestie: this probably only makes sense if the rule is actually part of a problem. otherwise it's giving notes app poetry you can't decode 😭

<stringification>

my $str = $ruleinfo->str;
str = str(ruleinfo)
str = ruleinfo.to_s

a string describing the ruleinfo, i.e. the reason why the corresponding rule has been created. it's the whole explanation in string form, iconic 👑

🦋 THE SOLUTION CLASS 🦋

a solution solves one specific problem. it's made up of multiple solution elements and every single one of them needs to be executed. no skipping steps, no half-doing it, we are doing the tasks 💪✨

🎀 ATTRIBUTES 🎀

  • Solver *solv; /* read only */ — $solution->{solv}, solution.solv, solution.solv. back pointer to the solver object. the classic 🫶
  • Id problemid; /* read only */ — $solution->{problemid}, solution.problemid, solution.problemid. the Id of the problem that this solution solves 🎯
  • Id id; /* read only */ — $solution->{id}, solution.id, solution.id. the Id of the solution. the first solution has Id 1, and they're numbered consecutively from there. 1, 2, 3... you get it 🔢

💫 METHODS 💫

Solutionelement *elements(bool expandreplaces = 0)
my @solutionelements = $solution->elements();
solutionelements = solution.elements()
solutionelements = solution.elements()

returns an array with all the elements that describe what needs to be done to actually implement this specific solution. and here's the tea: if expandreplaces is true, elements of type SOLVER_SOLUTION_REPLACE get replaced by one or more elements replace elements describing the policy mismatches. swap szn 🔄💅

int element_count()
my $cnt = $solution->solution_count();
cnt = solution.element_count()
cnt = solution.element_count()

returns how many solution elements there are without creating any objects — efficient queen ✨. but heads up: the count does not match the number of objects returned by the elements() method if expandreplaces is set to true. do not come for me, it's literally what it says 😭

💖 THE SOLUTIONELEMENT CLASS 💖

a solution element describes a single action of a solution. and the action is always one of exactly two things: either remove one specific job, or add a new job that installs or erases a single specific package. no third option, bestie, it's giving "two buttons and a dream" 🎀

🎀 ATTRIBUTES 🎀

  • Solver *solv; /* read only */ — $solutionelement->{solv}, solutionelement.solv, solutionelement.solv. back pointer to the solver object 🫶
  • Id problemid; /* read only */ — $solutionelement->{problemid}, solutionelement.problemid, solutionelement.problemid. the Id of the problem that the element (partly) solves. partly!! because teamwork makes the dream work 🌈
  • Id solutionid; /* read only */ — $solutionelement->{solutionid}, solutionelement.solutionid, solutionelement.solutionid. the Id of the solution this element is a part of 🧩
  • Id id; /* read only */ — $solutionelement->{id}, solutionelement.id, solutionelement.id. the Id of the solution element. first element gets Id 1, numbered consecutively, same deal as before 🔢
  • Id type; /* read only */ — $solutionelement->{type}, solutionelement.type, solutionelement.type. the type of the solution element. for the existing types, constant section of the solver class, you know the drill by now 📖
  • Solvable *solvable; /* read only */ — $solutionelement->{solvable}, solutionelement.solvable, solutionelement.solvable. the installed Solvable that needs to be replaced for replacement elements. she's leaving, respectfully ✌️
  • Solvable *replacement; /* read only */ — $solutionelement->{replacement}, solutionelement.replacement, solutionelement.replacement. the Solvable that needs to be installed to fix the problem. the glow-up incoming 💚
  • int jobidx; /* read only */ — $solutionelement->{jobidx}, solutionelement.jobidx, solutionelement.jobidx. the index of the job that needs to be removed to fix the problem, or -1 if the element is some other type. but — and this is a real note, not a vibe — it's better to change the job to SOLVER_NOOP type so the numbering of the other elements doesn't get disturbed. and this one works for both SOLVER_SOLUTION_JOB and SOLVER_SOLUTION_POOLJOB, okay? two types, one attribute 🫡

💫 METHODS 💫

Solutionelement *replaceelements()
my @solutionelements = $solutionelement->replaceelements();
solutionelements = solutionelement.replaceelements()
solutionelements = solutionelement.replaceelements()

if the solution element is of type SOLVER_SOLUTION_REPLACE, this returns an array of elements describing the policy mismatches. otherwise? it returns a copy of the element. and yes, peep the expandreplaces option over in the solution's elements() method, they're besties 👯‍♀️

int illegalreplace()
my $illegal = $solutionelement->illegalreplace();
illegal = solutionelement.illegalreplace()
illegal = solutionelement.illegalreplace()

returns an integer with all the policy mismatch bits or-ed together, or zero if there was no policy mismatch at all. for the actual constants, check the policy error constants in the solver class 🔥

Job Job()
my $job = $solutionelement->Job();
illegal = solutionelement.Job()
illegal = solutionelement.Job()

creates a job that implements the solution element. here's the play, bestie: add this job to the array of jobs for all elements of type different to SOLVER_SOLUTION_JOB and SOLVER_SOLUTION_POOLJOB. for those latter two, a SOLVER_NOOB Job is created, and you should replace the old job with the new one. out with the old, in with the new 💅✨

<stringification>

my $str = $solutionelement->str;
str = str(solutionelement)
str = solutionelement.to_s

a string describing the change that the solution element consists of. the lil' summary of the lil' action 🎀

💖 THE TRANSACTION CLASS 💖

okay bestie so a Transaction is literally the receipts of a solver run — it describes the output. A transaction holds a bunch of transaction elements, and each one is either a new package getting installed or an already-installed package getting yeeted. The Transaction class also has a classify() method that sorts the elements into different groups so you can present a transaction to a user in a way that actually makes sense. iconic ✨

🎀 CONSTANTS 🎀

Transaction element types, both active and passive

  • SOLVER_TRANSACTION_IGNORE — this element does literally nothing. It's used to map element types that don't match the view mode. it's giving placeholder energy 💅
  • SOLVER_TRANSACTION_INSTALL — this element installs a package. ✨
  • SOLVER_TRANSACTION_ERASE — this element erases a package. bye bestie 👋
  • SOLVER_TRANSACTION_MULTIINSTALL — this element installs a package with a different version while keeping the other versions installed. polyamorous package behavior fr
  • SOLVER_TRANSACTION_MULTIREINSTALL — this element reinstalls an installed package, keeping the other versions installed.

Transaction element types, active view

  • SOLVER_TRANSACTION_REINSTALL — this element re-installs a package, i.e. installs the same package again. 🔁
  • SOLVER_TRANSACTION_CHANGE — this element installs a package with the same name, same version, same architecture, but different content. 😭 the audacity
  • SOLVER_TRANSACTION_UPGRADE — this element installs a newer version of an installed package. glow up ⬆️🌸
  • SOLVER_TRANSACTION_DOWNGRADE — this element installs an older version of an installed package. not the downgrade 😭
  • SOLVER_TRANSACTION_OBSOLETES — this element installs a package that obsoletes an installed package. it said "you're replaced bestie"

Transaction element types, passive view

  • SOLVER_TRANSACTION_REINSTALLED — this element re-installs a package, i.e. installs the same package again.
  • SOLVER_TRANSACTION_CHANGED — this element replaces an installed package with one of the same name, version and architecture, but different content.
  • SOLVER_TRANSACTION_UPGRADED — this element replaces an installed package with a new version.
  • SOLVER_TRANSACTION_DOWNGRADED — this element replaces an installed package with an old version.
  • SOLVER_TRANSACTION_OBSOLETED — this element replaces an installed package with a package that obsoletes it.

Pseudo element types for showing extra information used by classify()

  • SOLVER_TRANSACTION_ARCHCHANGE — this element replaces an installed package with a package of a different architecture.
  • SOLVER_TRANSACTION_VENDORCHANGE — this element replaces an installed package with a package of a different vendor.

Transaction mode flags

  • SOLVER_TRANSACTION_SHOW_ACTIVE — filter for active view types. The default is to return the passive view type, i.e. to show how the installed packages get changed.
  • SOLVER_TRANSACTION_SHOW_OBSOLETES — do not map the obsolete view type into INSTALL/ERASE elements.
  • SOLVER_TRANSACTION_SHOW_ALL — if multiple packages replace an installed package, only the best of them is kept as an OBSOLETE element, and the other ones get mapped to INSTALL/ERASE elements. That's because most applications want to show just one package replacing the installed one. The SOLVER_TRANSACTION_SHOW_ALL flag makes the library keep all OBSOLETE elements. 👑
  • SOLVER_TRANSACTION_SHOW_MULTIINSTALL — the library maps MULTIINSTALL elements to simple INSTALL elements. This flag can be used to disable that mapping.
  • SOLVER_TRANSACTION_CHANGE_IS_REINSTALL — use this flag if you want to map CHANGE elements to the REINSTALL type.
  • SOLVER_TRANSACTION_OBSOLETE_IS_UPGRADE — use this flag if you want to map OBSOLETE elements to the UPGRADE type.
  • SOLVER_TRANSACTION_MERGE_ARCHCHANGES — do not add extra categories for every architecture change; instead cumulate them in one category.
  • SOLVER_TRANSACTION_MERGE_VENDORCHANGES — do not add extra categories for every vendor change; instead cumulate them in one category.
  • SOLVER_TRANSACTION_RPM_ONLY — special view mode that just returns IGNORE, ERASE, INSTALL and MULTIINSTALL elements. Useful if you want to find out what to feed to the underlying package manager. 🍓

Transaction order flags

  • SOLVER_TRANSACTION_KEEP_ORDERDATA — do not throw away the dependency graph used for ordering the transaction. You need this flag if you want to do manual ordering.

🌈 ATTRIBUTES 🌈

Pool *pool;                             /* read only */
$trans->{pool}
trans.pool
trans.pool

Back pointer to pool. gotta know where you came from bestie 🫶

🦋 METHODS 🦋

bool isempty()
$trans->isempty()
trans.isempty()
trans.isempty?

Returns true if the transaction does not do anything, i.e. it has no elements. the chillest transaction ✨

Solvable *newsolvables()
my @newsolvables = $trans->newsolvables();
newsolvables = trans.newsolvables()
newsolvables = trans.newsolvables()

Return all packages that are to be installed by the transaction. These are the packages that need to be downloaded from the repositories. 📥

Solvable *keptsolvables()
my @keptsolvables = $trans->keptsolvables();
keptsolvables = trans.keptsolvables()
keptsolvables = trans.keptsolvables()

Return all installed packages that the transaction will keep installed. they're safe, they're staying 🥰

Solvable *steps()
my @steps = $trans->steps();
steps = trans.steps()
steps = trans.steps()

Return all solvables that need to be installed (if the returned solvable is not already installed) or erased (if the returned solvable is installed). A step is also called a transaction element. 💅

int steptype(Solvable *solvable, int mode)
my $type = $trans->steptype($solvable, $mode);
type = trans.steptype(solvable, mode)
type = trans.steptype(solvable, mode)

Return the transaction type of the specified solvable. See the CONSTANTS sections for the mode argument flags and the list of returned types.

TransactionClass *classify(int mode = 0)
my @classes = $trans->classify();
classes = trans.classify()
classes = trans.classify()

Group the transaction elements into classes so they can be displayed in a structured way. You can use various mapping mode flags to tweak the result to match your preferences — see the mode argument flag in the CONSTANTS section. See the TransactionClass class for how to deal with the returned objects. 🎀

Solvable othersolvable(Solvable *solvable)
my $other = $trans->othersolvable($solvable);
other = trans.othersolvable(solvable)
other = trans.othersolvable(solvable)

Return the “other” solvable for a given solvable. For installed packages, the other solvable is the best package with the same name that replaces the installed package, or — if the package does not get replaced by one with the same name — the best package of the obsoleting packages.

For to-be-installed packages, the “other” solvable is the best installed package with the same name that will be replaced, or — if the new package does not replace a package with the same name — the best packages of all the packages that are obsoleted.

So basically, the “other” solvable is normally the package that is also shown for a given package. it's giving plus-one energy 💜

Solvable *allothersolvables(Solvable *solvable)
my @others = $trans->allothersolvables($solvable);
others = trans.allothersolvables(solvable)
others = trans.allothersolvables(solvable)

For installed packages, returns all of the packages that replace us. For to-be-installed packages, returns all of the packages that the new package replaces. The special “other” solvable is always the first entry of the returned array. 🔥

long long calc_installsizechange()
my $change = $trans->calc_installsizechange();
change = trans.calc_installsizechange()
change = trans.calc_installsizechange()

Return the size change of the installed system in kilobytes (kibibytes). check that disk space before you commit bestie 💀

void order(int flags = 0)
$trans->order();
trans.order()
trans.order()

Order the steps in the transaction so that dependent packages are updated before the packages that depend on them. For rpm, you can also use rpmlib's ordering functionality — but debian's dpkg does not provide a way to order a transaction. not dpkg catching strays 😭

👑 ACTIVE/PASSIVE VIEW 👑

Active view lists what new packages get installed, while passive view shows what happens to the installed packages. Most of the time there's not much difference between the two modes, but things get interesting if multiple packages get replaced by one new package.

Say you have installed packages A-1-1 and B-1-1, and now you install A-2-1 which has a new dependency that obsoletes B. The transaction elements will be

updated   A-1-1 (other: A-2-1)
obsoleted B-1-1 (other: A-2-1)

in passive mode, but

update A-2-1 (other: A-1-1)
erase  B

in active mode. If the mode contains SOLVER_TRANSACTION_SHOW_ALL, the passive mode list will be unchanged but the active mode list will just contain A-2-1. 🌈

🎀 THE TRANSACTIONCLASS CLASS 🎀

Objects of this type are returned by the classify() Transaction method. the sorting hat of transactions ✨

🌸 ATTRIBUTES 🌸

Transaction *transaction;               /* read only */
$class->{transaction}
class.transaction
class.transaction

Back pointer to the transaction object. 🫶

int type;                               /* read only */
$class->{type}
class.type
class.type

The type of the transaction elements in the class.

int count;                              /* read only */
$class->{count}
class.count
class.count

The number of elements in the class. 🔢

const char *fromstr;
$class->{fromstr}
class.fromstr
class.fromstr

The old vendor or architecture.

const char *tostr;
$class->{tostr}
class.tostr
class.tostr

The new vendor or architecture. ✨

Id fromid;
$class->{fromid}
class.fromid
class.fromid

The id of the old vendor or architecture.

Id toid;
$class->{toid}
class.toid
class.toid

The id of the new vendor or architecture. 💅

💖 METHODS 💖

void solvables();
my @solvables = $class->solvables();
solvables = class.solvables()
solvables = class.solvables()

Return the solvables for all transaction elements in the class. 🦋

💖 CHECKSUMS 💖

Checksums (also called hashes, bestie) are literally how we make sure that downloaded data isn't corrupt 💀 — and also how we take a lil fingerprint of stuff to check if it's changed since last time. Two jobs, one vibe. ✨

🌸 CLASS METHODS

Chksum Chksum(Id type)
my $chksum = solv::Chksum->new($type);
chksum = solv.Chksum(type)
chksum = Solv::Chksum.new(type)

Make a checksum object, slay. And rn these are the types you can pick from, periodt:

REPOKEY_TYPE_MD5
REPOKEY_TYPE_SHA1
REPOKEY_TYPE_SHA224
REPOKEY_TYPE_SHA256
REPOKEY_TYPE_SHA384
REPOKEY_TYPE_SHA512

Those keys are constants in the solv class, iykyk. 💅

Chksum Chksum(Id type, const char *hex)
my $chksum = solv::Chksum->new($type, $hex);
chksum = solv.Chksum(type, hex)
chksum = Solv::Chksum.new(type, hex)

Make an already-finalized checksum object straight from a hex string. So easy. 🎀

Chksum Chksum_from_bin(Id type, char *bin)
my $chksum = solv::Chksum->from_bin($type, $bin);
chksum = solv.Chksum.from_bin(type, bin)
chksum = Solv::Chksum.from_bin(type, bin)

And this one makes an already-finalized checksum object from a binary checksum. 🫶

✨ ATTRIBUTES ✨

Id type;                        /* read only */
$chksum->{type}
chksum.type
chksum.type

Returns the type of the checksum object. Read only, so don't even try it. 👑

🦋 METHODS 🦋

void add(const char *str)
$chksum->add($str);
chksum.add(str)
chksum.add(str)

Add a (binary) string to the checksum. Feed it bytes, it eats them. 🍓

void add_fp(FILE *fp)
$chksum->add_fp($file);
chksum.add_fp(file)
chksum.add_fp(file)

Add the contents of a file to the checksum. Whole file, into the hash. 💜

void add_stat(const char *filename)
$chksum->add_stat($filename);
chksum.add_stat(filename)
chksum.add_stat(filename)

Stats the file and adds the dev/ino/size/mtime member to the checksum. And okay important: if the stat fails, the members are zeroed. Not a vibe, but that's the deal. 😭

void add_fstat(int fd)
$chksum->add_fstat($fd);
chksum.add_fstat(fd)
chksum.add_fstat(fd)

Same as add_stat, literally, except you hand it a file descriptor instead of a filename. Easy swap. 🔥

unsigned char *raw()
my $raw = $chksum->raw();
raw = chksum.raw()
raw = chksum.raw()

Finalizes the checksum and hands you the result as raw bytes. Real talk — that means the result can totally contain NUL bytes or unprintable characters, so don't be shocked when your terminal acts weird. 💀

const char *hex()
my $raw = $chksum->hex();
raw = chksum.hex()
raw = chksum.hex()

Finalizes the checksum and gives it back as a hex string. Pretty, printable, iconic. ✨

const char *typestr()
my $typestr = $chksum->typestr();
typestr = chksum.typestr
typestr = chksum.typestr

Returns the type of the checksum as a string, like "sha256". No cap. 🌸

<equality>
if ($chksum1 == $chksum2)
if chksum1 == chksum2:
if chksum1 == chksum2

Checksums are equal if they're the same type and the finalized results are the same. Both conditions, bestie, no shortcuts. 🫶

<stringification>
my $str = $chksum->str;
str = str(chksum)
str = chksum.to_s

If the checksum is finished, you get it back as a "<type>:<hex>" string. Otherwise you get "<type>:unfinished". That's the whole tea. ☕

🎀 FILE MANAGEMENT 🎀

Okay so these functions exist for a very specific reason: libsolv uses standard FILE pointers to read and write files, but languages like perl have their own whole separate implementation of files. So here we are. Also — these libsolv functions support decompression and compression, and the algorithm gets picked by looking at the file name extension. Sneaky but genius. 👑

FILE *xfopen(char *fn, char *mode = "r")
my $file = solv::xfopen($path);
file = solv.xfopen(path)
file = Solv::xfopen(path)

Opens a file at the specified path. The mode argument gets passed straight on to the stdio library, so it behaves exactly how you'd expect. 💅

FILE *xfopen_fd(char *fn, int fileno)
my $file = solv::xfopen_fd($path, $fileno);
file = solv.xfopen_fd(path, fileno)
file = Solv::xfopen_fd(path, fileno)

Creates a file handle from the specified file descriptor. Now listen — the path argument is only used to select the correct (de-)compression algorithm, so use an empty path if you want to make absolutely sure you're reading/writing raw data. Also the file descriptor gets dup()ed before the file handle is created. Important detail, don't forget it. ✨

🌈 METHODS 🌈

int fileno()
my $fileno = $file->fileno();
fileno = file.fileno()
fileno = file.fileno()

Returns the file descriptor of the file. If the file isn't open, you get -1. Rude but fair. 🙈

void cloexec(bool state)
$file->cloexec($state);
file.cloexec(state)
file.cloexec(state)

Sets the close-on-exec flag of the file descriptor. And here's the thing — xfopen returns files with close-on-exec turned on, so if you want to pass a file to some other process you need to call cloexec(0) before calling exec. Yeah. Remember that one or you'll be so confused. 💀

int dup()
my $fileno = $file->dup();
fileno = file.dup()
fileno = file.dup()

Returns a copy of the descriptor of the file. If the file isn't open, -1. Same energy as fileno(). 🦋

bool flush()
$file->flush();
file.flush()
file.flush()

Flushes the file. Returns false if there was an error. And fun fact: flushing a closed file always returns true. Closed file says "sure bestie, all flushed" 😭

bool close()
$file->close();
file.close()
file.close()

Closes the file. This one's needed for languages like Ruby that don't destruct objects right after they stop being referenced. In that case it's good style to close open files so the file descriptors get freed right away. Returns false if there was an error. Do it. Close your files. 👑💖

👑 THE REPODATA CLASS 👑

okay so bestie, Repodata is the whole storage situation for attributes of packages and the repository itself. Every single repository can have multiple repodata areas, iconic behaviour ngl. 🌈

You literally only need to reach in and poke them directly if you're out here implementing lazy downloading of repository data (iykyk 💅). Repodata areas get born when you call the repository's add_repodata() method, or when you use repo_add methods without the REPO_REUSE_REPODATA or REPO_USE_LOADING flag. No flag, no reuse, periodt.

🎀 ATTRIBUTES 🎀

  • Repo *repo; — read only. It's a back pointer to the repository object.
$data->{repo}
data.repo
data.repo
  • Id id; — read only. The id of the repodata area. Heads up bestie: repodata ids from different repositories can totally overlap, so do not go comparing them across repos, that's a trap. 😭
$data->{id}
data.id
data.id

✨ METHODS ✨

  • internalize() — Internalizes newly added data. The lookup functions will only see the new data after it's been internalized. So like, if you forgot to internalize, those lookups are giving ghost town. 👻
$data->internalize();
data.internalize()
data.internalize()
  • bool write(FILE *fp) — Writes the contents of the repodata area out as a solv file. 📝
$data->write($fp);
data.write(fp)
data.write(fp)
  • Id str2dir(const char *dir, bool create = 1)
my $did = data->str2dir($dir);
did = data.str2dir(dir)
did = data.str2dir(dir)
  • const char *dir2str(Id did, const char *suffix = 0)
$dir = pool->dir2str($did);
dir = pool.dir2str(did)
dir = pool.dir2str(did)

These two convert a string (directory) into an Id and back again, bestie. And here's the important bit: if the string is currently not in the pool and create is false, then zero gets returned. Zero. Zilch. Nada. 🚫

  • void add_dirstr(Id solvid, Id keyname, Id dir, const char *str) — Adds a file path that's made up of a dirname Id plus a basename string. Slay.
$data->add_dirstr($solvid, $keyname, $dir, $string);
data.add_dirstr(solvid, keyname, dir, string)
data.add_dirstr(solvid, keyname, dir, string)
  • bool add_solv(FILE *fp, int flags = 0) — Replaces a stub repodata object with data from a solv file. This method auto-adds the REPO_USE_LOADING flag for you, and it should only be used from a load callback. Don't be wildin' with this one. 🚨
$data->add_solv($fp);
data.add_solv(fp)
data.add_solv(fp)
  • void create_stubs() — Creates stub repodatas out of the information stored in the repodata meta area. 🪄
$data->create_stubs();
data.create_stubs()
data.create_stubs()
  • void extend_to_repo() — Extends the repodata so it has the same size as the repo it belongs to. You need this when you're setting up a new extension repodata so it matches the repository size, and you also need it when switching to a just-written repodata extension — that way the repodata matches the written extension, which is always the size of the repo. Matching sizes? We love to see it. 🦋
$data->extend_to_repo();
data.extend_to_repo()
data.extend_to_repo()
  • <equality> — Two repodata objects are equal if they belong to the same repository and have the same id. Both conditions, no shortcuts. 💖
if ($data1 == $data2)
if data1 == data2:
if data1 == data2

🔍 DATA RETRIEVAL METHODS 🔍

These are the lookup functions, and they return the data element stored in the specified solvable. Real talk though: these methods probably only make sense for pulling data from the special SOLVID_META solvid, the one that stores repodata meta information. That's the whole point. 💅

  • const char *lookup_str(Id solvid, Id keyname)
my $string = $data->lookup_str($solvid, $keyname);
string = data.lookup_str(solvid, keyname)
string = data.lookup_str(solvid, keyname)
  • const char *lookup_id(Id solvid, Id keyname)
my $string = $data->lookup_id($solvid, $keyname);
string = data.lookup_id(solvid, keyname)
string = data.lookup_id(solvid, keyname)
  • unsigned long long lookup_num(Id solvid, Id keyname, unsigned long long notfound = 0)
my $num = $data->lookup_num($solvid, $keyname);
num = data.lookup_num(solvid, keyname)
num = data.lookup_num(solvid, keyname)
  • bool lookup_void(Id solvid, Id keyname)
my $bool = $data->lookup_void($solvid, $keyname);
bool = data.lookup_void(solvid, keyname)
bool = data.lookup_void(solvid, keyname)
  • Id *lookup_idarray(Id solvid, Id keyname)
my @ids = $data->lookup_idarray($solvid, $keyname);
ids = data.lookup_idarray(solvid, keyname)
ids = data.lookup_idarray(solvid, keyname)
  • Chksum lookup_checksum(Id solvid, Id keyname)
my $chksum = $data->lookup_checksum($solvid, $keyname);
chksum = data.lookup_checksum(solvid, keyname)
chksum = data.lookup_checksum(solvid, keyname)

💾 DATA STORAGE METHODS 💾

  • void set_str(Id solvid, Id keyname, const char *str)
$data->set_str($solvid, $keyname, $str);
data.set_str(solvid, keyname, str)
data.set_str(solvid, keyname, str)
  • void set_id(Id solvid, Id keyname, DepId id)
$data->set_id($solvid, $keyname, $id);
data.set_id(solvid, keyname, id)
data.set_id(solvid, keyname, id)
  • void set_num(Id solvid, Id keyname, unsigned long long num)
$data->set_num($solvid, $keyname, $num);
data.set_num(solvid, keyname, num)
data.set_num(solvid, keyname, num)
  • void set_void(Id solvid, Id keyname)
$data->set_void($solvid, $keyname);
data.set_void(solvid, keyname)
data.set_void(solvid, keyname)
  • void set_poolstr(Id solvid, Id keyname, const char *str)
$data->set_poolstr($solvid, $keyname, $str);
data.set_poolstr(solvid, keyname, str)
data.set_poolstr(solvid, keyname, str)
  • void set_checksum(Id solvid, Id keyname, Chksum *chksum)
$data->set_checksum($solvid, $keyname, $chksum);
data.set_checksum(solvid, keyname, chksum)
data.set_checksum(solvid, keyname, chksum)
  • void set_sourcepkg(Id solvid, const char *sourcepkg)
$data.set_sourcepkg($solvid, $sourcepkg);
data.set_sourcepkg(solvid, sourcepkg)
data.set_sourcepkg(solvid, sourcepkg)
  • void set_location(Id solvid, unsigned int mediano, const char *location)
$data.set_location($solvid, $mediano, $location);
data.set_location(solvid, mediano, location)
data.set_location(solvid, mediano, location)
  • void add_idarray(Id solvid, Id keyname, DepId id)
$data->add_idarray($solvid, $keyname, $id);
data.add_idarray(solvid, keyname, id)
data.add_idarray(solvid, keyname, id)
  • Id new_handle()
my $handle = $data->new_handle();
handle = data.new_handle()
handle = data.new_handle()
  • void add_flexarray(Id solvid, Id keyname, Id handle)
$data->add_flexarray($solvid, $keyname, $handle);
data.add_flexarray(solvid, keyname, handle)
data.add_flexarray(solvid, keyname, handle)
  • void unset(Id solvid, Id keyname)
$data->unset($solvid, $keyname);
data.unset(solvid, keyname)
data.unset(solvid, keyname)

These are the data storage methods, and ngl they're probably only useful for storing data in that special SOLVID_META solvid that holds repodata meta information. ✨

Careful though bestie: repodata areas can have their own Id pool (peep the REPO_LOCALPOOL flag), so be careful if you need to store ids — that's a whole different id space and it will humble you. 😭

Arrays get created by calling the add function once for every element. A flexarray is an array of sub-structures, so you call new_handle to create a new structure, use the handle as the solvid to fill that structure with data, and then call add_flexarray to actually put the structure into the array. Chef's kiss. 👑

🌸 THE DATAPOS CLASS 🌸

Datapos objects describe a specific position in the repository data area, which means they're only valid until the repository gets modified in some way. The moment things shift, that position is giving expired. 💀

You can create Datapos objects with the pos() and parentpos() methods of a Datamatch object, or by accessing the "meta" attribute of a repository. Easy. 🫶

🎀 ATTRIBUTES 🎀

  • Repo *repo; — read only. Back pointer to the repository object. Same energy as before.
$data->{repo}
data.repo
data.repo

✨ METHODS ✨

  • Dataiterator(Id keyname, const char *match, int flags) — Creates a Dataiterator at the position of the datapos object. 🧚
my $di = $datapos->Dataiterator($keyname, $match, $flags);
di = datapos.Dataiterator(keyname, match, flags)
di = datapos.Dataiterator(keyname, match, flags)
  • const char *lookup_deltalocation(unsigned int *OUTPUT) — Returns a tuple with the on-media location and an optional media number for a delta rpm. Obviously this only works if the data position is pointing at a structure that's describing a delta rpm. No delta rpm, no delta location. 🤷‍♀️
my ($location, $mediano) = $datapos->lookup_deltalocation();
location, mediano = datapos.lookup_deltalocation()
location, mediano = datapos.lookup_deltalocation()
  • const char *lookup_deltaseq() — Returns the delta rpm sequence from the structure describing a delta rpm. 🍓
my $seq = $datapos->lookup_deltaseq();
seq = datapos.lookup_deltaseq();
seq = datapos.lookup_deltaseq();

🔍 DATA RETRIEVAL METHODS 🔍

  • const char *lookup_str(Id keyname)
my $string = $datapos->lookup_str($keyname);
string = datapos.lookup_str(keyname)
string = datapos.lookup_str(keyname)
  • Id lookup_id(Id solvid, Id keyname)
my $id = $datapos->lookup_id($keyname);
id = datapos.lookup_id(keyname)
id = datapos.lookup_id(keyname)
  • unsigned long long lookup_num(Id keyname, unsigned long long notfound = 0)
my $num = $datapos->lookup_num($keyname);
num = datapos.lookup_num(keyname)
num = datapos.lookup_num(keyname)
  • bool lookup_void(Id keyname)
my $bool = $datapos->lookup_void($keyname);
bool = datapos.lookup_void(keyname)
bool = datapos.lookup_void(keyname)
  • Id *lookup_idarray(Id keyname)
my @ids = $datapos->lookup_idarray($keyname);
ids = datapos.lookup_idarray(keyname)
ids = datapos.lookup_idarray(keyname)
  • Chksum lookup_checksum(Id keyname)
my $chksum = $datapos->lookup_checksum($keyname);
chksum = datapos.lookup_checksum(keyname)
chksum = datapos.lookup_checksum(keyname)

So these are the lookup functions, and here's the tea you cannot skip: the returned Ids are always translated into the Ids of the global pool — even if the repodata area has its own pool. Every single time. No exceptions. 💜

  • Dataiterator(Id keyname, const char *match = 0, int flags = 0) — Iterate over the matching data elements. See the Dataiterator class for more info, bestie. 🔥
my $di = $datapos->Dataiterator($keyname, $match, $flags);
di = datapos.Dataiterator(keyname, match, flags)
di = datapos.Dataiterator(keyname, match, flags)
for my $d (@$di)
for d in di:
for d in di

🌸 ATTRIBUTES 🌸 (the rest of them)

Solver *solv;                   /* read only */
$alternative->{solv}
alternative.solv
alternative.solv

Bestie this is just the lil back pointer to the solver object. it knows its parent, iconic 💫

Id type;                        /* read only */
$alternative->{type}
alternative.type
alternative.type

The type of the alternative. Quick lore dump: alternatives get made because of rule fulfillment, because of recommended packages, and because of suggested packages (currently unused, so don't get too excited). Scroll down for the list of valid types ✨

Rule rule;                      /* read only */
$alternative->{rule}
alternative.rule
alternative.rule

The rule that caused the creation of the alternative — aka SOLVER_ALTERNATIVE_TYPE_RULE. the origin story basically 🎀

Dep *dep;                       /* read only */
$ruleinfo->{dep}
ruleinfo.dep
ruleinfo.dep

The dependency that caused the creation of the alternative — that's your SOLVER_ALTERNATIVE_TYPE_RECOMMENDS situation. yes the field names here say ruleinfo, no that's not a typo on my part, that's just how the page ships 💀

Dep *depsolvable;               /* read only */
$ruleinfo->{depsolvable}
ruleinfo.depsolvable
ruleinfo.depsolvable

The package containing the dependency, again for SOLVER_ALTERNATIVE_TYPE_RECOMMENDS. the dep's home address 🏠

Solvable chosen;                /* read only */
$alternative->{chosen}
alternative.chosen
alternative.chosen

The solvable that the solver chose from the alternative's package set. the chosen one, no cap 👑

✨ CONSTANTS ✨

  • SOLVER_ALTERNATIVE_TYPE_RULE — the alternative was created when fulfilling a rule.
  • SOLVER_ALTERNATIVE_TYPE_RECOMMENDS — the alternative was created when fulfilling a recommends dependency.
  • SOLVER_ALTERNATIVE_TYPE_SUGGESTS — the alternative was created when fulfilling a suggests dependency.

🦋 METHODS 🦋

Solvable *choices()
my @choices = $alternative->choices();
choices = alternative.choices
choices = alternative.choices

Returns the set of solvables that the solver could choose from when creating the alternative. the whole menu of options bestie, it's giving choose-your-own-adventure 📖

<stringification>
my $str = $alternative->str;
str = str(alternative)
str = alternative.to_s

Returns a string describing the alternative. vibe check in string form 💅

💜 THE DECISION CLASS 💜

So a decision happens when the solver fulfills dependencies. It's either install this package to satisfy a dependency or conflict this dependency because it conflicts with another package or its own dependencies cannot be met. Most decisions come from rule processing, but there are a few other types too — like orphaned package handling and weak dependency handling. the solver's little diary entries fr fr 📓

🌸 ATTRIBUTES 🌸

Solver *solv;                   /* read only */
$decision->{solv}
decision.solv
decision.solv

Back pointer to the solver object. its ride-or-die reference 🫶

Id p;                           /* read only */
$decision->{p}
decision.p
decision.p

The decision package id — positive for installs and negative for conflicts. The sign is literally the whole personality 💚❤️

int reason;                     /* read only */
$decision->{reason}
decision.reason
decision.reason

The reason for the decision. Peep the SOLVER_REASON_ constants for the deets 🔍

int infoid;                     /* read only */
$decision->{infoid}
decision.infoid
decision.infoid

Extra info for the decision. For decisions caused by rule fulfillment, this is the rule id. bonus context, always appreciated ✨

Solvable solvable;              /* read only */
$decision->{solvable}
decision.solvable
decision.solvable

The decision package object itself. the main character of this decision 🎬

Rule rule()                     /* read only */
$decision->{rule}
decision.rule
decision.rule

The rule object for decisions that where caused by rule fulfilment. (that "where" is the page's, I'm just the messenger 😭)

🦋 METHODS 🦋

Ruleinfo info()
my $info = $decision->info();
info = decision.info()
info = decision.info()

Returns a Ruleinfo object describing the decision. Heads up bestie: some reasons like SOLVER_REASON_WEAKDEP are not caused by rules, but they can still be expressed by a Ruleinfo object. flexible like that 🧚

Ruleinfo *allinfos()
my @infos = $decision->allinfos();
infos = decision.allinfos()
infos = decision.allinfos()

Same as info(), except ALL the Ruleinfo objects describing the decision get returned. the full set, no crumbs left behind 💖

const char *reasonstr()
my str = $decision->reasonstr()
str = decision.reasonstr()
str = decision.reasonstr()

Returns a string describing why a decision was done — but without the decision itself. the why, not the what 👀

<stringification>
my $str = $decison->str;
str = str(decision)
str = decision.to_s

Returns a string describing the decision — but without the reason. (and yeah, $decison up there is exactly how it's spelled on the page, I am NOT fixing it, that's the assignment 😌)

🎀 THE DECISIONSET CLASS 🎀

A decisionset is a lil squad of multiple decisions that share the same reason and type, so they can be shown to the user as one single action. group project but it actually works 🫶

💖 ATTRIBUTES 💖

Solver *solv;                   /* read only */
$decision->{solv}
decision.solv
decision.solv

Back pointer to the solver object. again with the parent link, we love consistency 💅

Id p;                           /* read only */
$decision->{p}
decision.p
decision.p

The package id of the first decision — positive for installs and negative for conflicts. the leader of the pack 👑

int reason;                     /* read only */
$decision->{reason}
decision.reason
decision.reason

The reason for the decisions in the set. Go check the SOLVER_REASON_ constants 🔍

int type;                       /* read only */
$ruleinfo->{type}
ruleinfo.type
ruleinfo.type

The type of the decision info. See the constant section of the solver class for the rule type list and the special type list. iykyk ✨

Dep *dep;                       /* read only */
$ruleinfo->{dep}
ruleinfo.dep
ruleinfo.dep

The dependency that caused the decision. the root cause, the origin, the beginning of the lore 📜

Dep *dep_id;                    /* read only */
$ruleinfo->{dep_id}
ruleinfo.dep_id
ruleinfo.dep_id

The Id of the dependency that caused the decision. same dep, but as an id this time 🔢

🌈 METHODS 🌈

Decision *decisions()
my @decisions = $decisionset->decisions();
decisions = decisionset.decisions()
decisions = decisionset.decisions()

Returns all the decisions of the set. the whole squad, assembled 🫂

Solvable *solvables()
my @pkgs = $decisionset->solvables();
pkgs = decisionset.solvables()
pkgs = decisionset.solvables()

Returns all the packages that were decided in the set. every pkg that got a verdict 📦

const char *reasonstr()
my str = $decision->reasonstr();
str = decision.reasonstr()
str = decision.reasonstr()

Returns a string describing why the decisions were done — but without the decisions themself. (yep, "themself", word for word, don't @ me 😭)

<stringification>
my $str = $decison->str;
str = str(decision)
str = decision.to_s

Returns a string describing the decisions — but without the reason. so like... the what without the why, the mirror image of reasonstr() above. poetic honestly 🪞

👑 AUTHOR 👑

Michael Schroeder <mls@suse.de>

that's the whole legend right there, we stan 💖✨

and that's a wrap on the whole page bestie!! 🎉 this was part 15 of 15, so you have officially read every last byte of LIBSOLV-BINDINGS(3) — from the libsolv project, dated 10/21/2026, version stamp and all. go forth and bind some solvers, you absolute icon, periodt 💅🦋🌸

📦 where this page comes from