table of contents
- NAME
- PUBLIC ATTRIBUTES
- CREATION AND DESTRUCTION
- DEBUGGING AND ERROR REPORTING
- POOL CONFIGURATION
- ID POOL MANAGEMENT
- SOLVABLE FUNCTIONS
- DEPENDENCY MATCHING
- WHATPROVIDES INDEX
- UTILITY FUNCTIONS
- DATA LOOKUP
- JOB AND SELECTION FUNCTIONS
- ODDS AND ENDS
- ARCHITECTURE POLICIES
- VENDOR POLICIES
- BOOLEAN DEPENDENCIES
- NAMESPACE DEPENDENCIES
- AUTHOR
LIBSOLV-POOL(3) | LIBSOLV | LIBSOLV-POOL(3) |
NAME¶
libsolv-pool - Libsolv's pool objectPUBLIC ATTRIBUTES¶
void *appdataA no-purpose pointer free to use for the library user.
Freeing the pool simply discards the pointer.
Stringpool ss
The pool of unified strings.
Reldep *rels
The pool of unified relation dependencies.
int nrels
Number of allocated relation dependencies.
Repo **repos
The array of repository pointers, indexed by repository
Id.
int nrepos
Number of allocated repository array elements, i.e. the
size of the repos array.
int urepos
Number of used (i.e. non-zero) repository array
elements.
Repo *installed
Pointer to the repo holding the installed packages. You
are free to read this attribute, but you should use pool_set_installed() if
you want to change it.
Solvable *solvables
The array of Solvable objects.
int nsolvables
Number of Solvable objects, i.e. the size of the
solvables array. Note that the array may contain freed solvables, in that case
the repo pointer of the solvable will be zero.
int disttype
The distribution type of your system, e.g. DISTTYPE_DEB.
You are free to read this attribute, but you should use pool_setdisttype() if
you want to change it.
Id *whatprovidesdata
Multi-purpose Id storage holding zero terminated arrays
of Ids. pool_whatprovides() returns an offset into this data.
Map *considered
Optional bitmap that can make the library ignore
solvables. If a bitmap is set, only solvables that have a set bit in the
bitmap at their Id are considered usable.
int debugmask
A mask that defines which debug events should be
reported. pool_setdebuglevel() sets this mask.
Datapos pos
An object storing some position in the repository data.
Functions like dataiterator_set_pos() set this object, accessing data with a
pseudo solvable Id of SOLVID_POS uses it.
Queue pooljobs
A queue where fixed solver jobs can be stored. This jobs
are automatically added when solver_solve() is called, they are useful to
store configuration data like which packages should be multiversion
installed.
CREATION AND DESTRUCTION¶
Pool *pool_create();
void pool_free(Pool *pool);
DEBUGGING AND ERROR REPORTING¶
Constants¶
SOLV_FATALReport the error and call “exit(1)”
afterwards. You cannot mask this level. Reports to stderr instead of
stdout.
SOLV_ERROR
Used to report errors. Reports to stderr instead of
stdout.
SOLV_WARN
Used to report warnings.
SOLV_DEBUG_STATS
Used to report statistical data.
SOLV_DEBUG_RULE_CREATION
Used to report information about the solver’s
creation of rules.
SOLV_DEBUG_PROPAGATE
Used to report information about the solver’s unit
rule propagation process.
SOLV_DEBUG_ANALYZE
Used to report information about the solver’s
learnt rule generation mechanism.
SOLV_DEBUG_UNSOLVABLE
Used to report information about the solver dealing with
conflicting rules.
SOLV_DEBUG_SOLUTIONS
Used to report information about the solver creating
solutions to solve problems.
SOLV_DEBUG_POLICY
Used to report information about the solver searching for
an optimal solution.
SOLV_DEBUG_RESULT
Used by the debug functions to output results.
SOLV_DEBUG_JOB
Used to report information about the job rule generation
process.
SOLV_DEBUG_SOLVER
Used to report information about what the solver is
currently doing.
SOLV_DEBUG_TRANSACTION
Used to report information about the transaction
generation and ordering process.
SOLV_DEBUG_TO_STDERR
Write debug messages to stderr instead of stdout.
Functions¶
void pool_debug(Pool *pool, int type, const char *format, ...);
void pool_setdebuglevel(Pool *pool, int level);
void pool_setdebugmask(Pool *pool, int mask);
int pool_error(Pool *pool, int ret, const char *format, ...);
extern char *pool_errstr(Pool *pool);
void pool_setdebugcallback(Pool *pool, void (*debugcallback)(Pool *, void *data, int type, const char *str), void *debugcallbackdata);
POOL CONFIGURATION¶
Constants¶
DISTTYPE_RPMUsed for systems with use rpm as low level package
manager.
DISTTYPE_DEB
Used for systems with use dpkg as low level package
manager.
DISTTYPE_ARCH
Used for systems with use the arch linux package
manager.
DISTTYPE_HAIKU
Used for systems with use haiku packages.
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.
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 recently.
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 (used in RedHat and
Fedora) 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
Same as POOL_FLAG_OBSOLETEUSESCOLORS, but used to find
out if packages of the same name can be installed in parallel. For current
Fedora systems, POOL_FLAG_OBSOLETEUSESCOLORS should be false and
POOL_FLAG_IMPLICITOBSOLETEUSESCOLORS should be true (this is the default if
FEDORA is defined when libsolv is compiled).
POOL_FLAG_NOINSTALLEDOBSOLETES
New versions of rpm consider the obsoletes of installed
packages when checking for dependency, thus you may not install a package that
is obsoleted by some other installed package, unless you also erase the other
package.
POOL_FLAG_HAVEDISTEPOCH
Mandriva added a new field called distepoch that gets
checked in version comparison if the epoch/version/release of two packages are
the same.
POOL_FLAG_NOOBSOLETESMULTIVERSION
If a package is installed in multiversionmode, rpm used
to ignore both the implicit obsoletes and the obsolete dependency of a
package. This was changed to ignoring just the implicit obsoletes, thus you
may install multiple versions of the same name, but obsoleted packages still
get removed.
POOL_FLAG_ADDFILEPROVIDESFILTERED
Make the addfileprovides method only add files from the
standard locations (i.e. the “bin” and “etc”
directories). This is useful if you have only few packages that use
non-standard file dependencies, but you still wand the fast speed that
addfileprovides() generates.
Functions¶
void pool_setdisttype(Pool *pool, int disttype);
int pool_set_flag(Pool *pool, int flag, int value);
int pool_get_flag(Pool *pool, int flag);
void pool_set_rootdir(Pool *pool, const char *rootdir);
const char *pool_get_rootdir(Pool *pool);
char *pool_prepend_rootdir(Pool *pool, const char *dir);
char *pool_prepend_rootdir_tmp(Pool *pool, const char *dir);
void pool_set_installed(Pool *pool, Repo *repo);
void pool_set_languages(Pool *pool, const char **languages, int nlanguages);
void pool_setarch(Pool *pool, const char *arch);
void pool_setarchpolicy(Pool *, const char *);
void pool_addvendorclass(Pool *pool, const char **vendorclass);
void pool_setvendorclasses(Pool *pool, const char **vendorclasses);
void pool_set_custom_vendorcheck(Pool *pool, int (*vendorcheck)(Pool *, Solvable *, Solvable *));
void pool_setloadcallback(Pool *pool, int (*cb)(Pool *, Repodata *, void *), void *loadcbdata);
void pool_setnamespacecallback(Pool *pool, Id (*cb)(Pool *, void *, Id, Id), void *nscbdata);
ID POOL MANAGEMENT¶
Constants¶
ID_EMPTYThe Id of the empty string, it is always Id 1.
REL_LT
Represents a “<” relation.
REL_EQ
Represents a “=” relation.
REL_GT
Represents a “>” relation. You can use
combinations of REL_GT, REL_EQ, and REL_LT or-ed together to create any
relation you like.
REL_AND
A boolean AND operation, the “name” and
“evr” parts of the relation can be two sub-dependencies.
Packages must match both parts of the dependency.
REL_OR
A boolean OR operation, the “name” and
“evr” parts of the relation can be two sub-dependencies.
Packages can match any part of the dependency.
REL_WITH
Like REL_AND, but packages mast match both dependencies
simultaneously. See the section about boolean dependencies about more
information.
REL_NAMESPACE
A special namespace relation. See the section about
namespace dependencies for more information.
REL_ARCH
A architecture filter dependency. The
“name” part of the relation is a sub-dependency, the
“evr” part is the Id of an architecture that the matching
packages must have (note that this is an exact match ignoring architecture
policies).
REL_FILECONFLICT
An internal file conflict dependency used to represent
file conflicts. See the pool_add_fileconflicts_deps() function.
REL_COND
A conditional dependency, the “name”
sub-dependency is only considered if the “evr” sub-dependency is
fulfilled. See the section about boolean dependencies about more
information.
REL_COMPAT
A compat dependency used in Haiku to represent version
ranges. The “name” part is the actual version, the
“evr” part is the backwards compatibility version.
Functions¶
Id pool_str2id(Pool *pool, const char *str, int create);
Id pool_strn2id(Pool *pool, const char *str, unsigned int len, int create);
Id pool_rel2id(Pool *pool, Id name, Id evr, int flags, int create);
Id pool_id2langid(Pool *pool, Id id, const char *lang, int create);
const char *pool_id2str(const Pool *pool, Id id);
const char *pool_id2rel(const Pool *pool, Id id);
const char *pool_id2evr(const Pool *pool, Id id);
const char *pool_dep2str(Pool *pool, Id id);
void pool_freeidhashes(Pool *pool);
SOLVABLE FUNCTIONS¶
Solvable *pool_id2solvable(const Pool *pool, Id p);
const char *pool_solvid2str(Pool *pool, Id p);
const char *pool_solvable2str(Pool *pool, Solvable *s);
DEPENDENCY MATCHING¶
Constants¶
EVRCMP_COMPARECompare all parts of the version, treat missing parts as
empty strings.
EVRCMP_MATCH_RELEASE
A special mode for rpm version string matching. If a
version misses a release part, it matches all releases. In that case the
special values “-2” and “2” are returned,
depending on which of the two versions did not have a release part.
EVRCMP_MATCH
A generic match, missing parts always match.
EVRCMP_COMPARE_EVONLY
Only compare the epoch and the version parts, ignore the
release part.
Functions¶
int pool_evrcmp(const Pool *pool, Id evr1id, Id evr2id, int mode);
int pool_evrcmp_str(const Pool *pool, const char *evr1, const char *evr2, int mode);
int pool_evrmatch(const Pool *pool, Id evrid, const char *epoch, const char *version, const char *release);
int pool_match_dep(Pool *pool, Id d1, Id d2);
int pool_match_nevr(Pool *pool, Solvable *s, Id d);
WHATPROVIDES INDEX¶
void pool_createwhatprovides(Pool *pool);
void pool_freewhatprovides(Pool *pool);
Id pool_whatprovides(Pool *pool, Id d);
Id *pool_whatprovides_ptr(Pool *pool, Id d);
Id pool_queuetowhatprovides(Pool *pool, Queue *q);
void pool_addfileprovides(Pool *pool);
void pool_addfileprovides_queue(Pool *pool, Queue *idq, Queue *idqinst);
void pool_flush_namespaceproviders(Pool *pool, Id ns, Id evr);
void pool_add_fileconflicts_deps(Pool *pool, Queue *conflicts);
UTILITY FUNCTIONS¶
char *pool_alloctmpspace(Pool *pool, int len);
void pool_freetmpspace(Pool *pool, const char *space);
const char *pool_bin2hex(Pool *pool, const unsigned char *buf, int len);
char *pool_tmpjoin(Pool *pool, const char *str1, const char *str2, const char *str3);
char *pool_tmpappend(Pool *pool, const char *str1, const char *str2, const char *str3);
DATA LOOKUP¶
Constants¶
SOLVID_POSUse the data position stored in the pool for the lookup
instead of looking up the data of a solvable.
SOLVID_META
Use the data stored in the meta section of a repository
(or repodata area) instead of looking up the data of a solvable. This constant
does not work for the pool’s lookup functions, use it for the
repo’s or repodata’s lookup functions instead. It’s just
listed for completeness.
Functions¶
const char *pool_lookup_str(Pool *pool, Id solvid, Id keyname);
unsigned long long pool_lookup_num(Pool *pool, Id solvid, Id keyname, unsigned long long notfound);
Id pool_lookup_id(Pool *pool, Id solvid, Id keyname);
int pool_lookup_idarray(Pool *pool, Id solvid, Id keyname, Queue *q);
int pool_lookup_void(Pool *pool, Id solvid, Id keyname);
const char *pool_lookup_checksum(Pool *pool, Id solvid, Id keyname, Id *typep);
const unsigned char *pool_lookup_bin_checksum(Pool *pool, Id solvid, Id keyname, Id *typep);
const char *pool_lookup_deltalocation(Pool *pool, Id solvid, unsigned int *medianrp);
void pool_search(Pool *pool, Id solvid, Id keyname, const char *match, int flags, int (*callback)(void *cbdata, Solvable *s, Repodata *data, Repokey *key, KeyValue *kv), void *cbdata);
JOB AND SELECTION FUNCTIONS¶
A Job consists of two Ids, how and what. The how part describes the action, the job flags, and the selection method while the what part is in input for the selection. A Selection is a queue consisting of multiple jobs (thus the number of elements in the queue must be a multiple of two). See the Solver manpage for more information about jobs.const char *pool_job2str(Pool *pool, Id how, Id what, Id flagmask);
void pool_job2solvables(Pool *pool, Queue *pkgs, Id how, Id what);
int pool_isemptyupdatejob(Pool *pool, Id how, Id what);
const char *pool_selection2str(Pool *pool, Queue *selection, Id flagmask);
ODDS AND ENDS¶
void pool_freeallrepos(Pool *pool, int reuseids);
void pool_clear_pos(Pool *pool);
ARCHITECTURE POLICIES¶
An architecture policy defines a list of architectures that can be installed on the system, and also the relationship between them (i.e. the ordering). Architectures can be delimited with three different characters: ':'No relationship between the architectures. A package of
one architecture can not be replaced with one of the other architecture.
'>'
The first architecture is better than the second one. An
installed package of the second architecture may be replaced with one from the
first architecture and vice versa. The solver will select the better
architecture if the versions are the same.
'='
The two architectures are freely exchangeable. Used to
define aliases for architectures.
An example would be 'x86_64:i686=athlon>i586'. This means that x86_64
packages can only be replaced by other x86_64 packages, i686 packages can be
replaced by i686 and i586 packages (but i686 packages will be preferred) and
athlon is another name for the i686 architecture.
You can turn off the architecture replacement checks with the Solver’s
SOLVER_FLAG_ALLOW_ARCHCHANGE flag.
VENDOR POLICIES¶
Different vendors often compile packages with different features, so Libsolv only replace installed packages of one vendor with packages coming from the same vendor. Also, while the version of a package is normally defined by the upstream project, the release part of the version is set by the vendor’s package maintainer, so it’s not meaningful to do version comparisons for packages coming from different vendors. Vendor in this case means the SOLVABLE_VENDOR string stored in each solvable. Sometimes a vendor changes names, or multiple vendors form a group that coordinate their package building, so libsolv offers a way to define that a group of vendors are compatible. You do that be defining vendor equivalence classes, packages from a vendor from one class may be replaced with packages from all the other vendors in the class. There can be multiple equivalence classes, the set of allowed vendor changes for an installed package is calculated by building the union of all of the equivalence classes the vendor of the installed package is part of. You can turn off the architecture replacement checks with the Solver’s SOLVER_FLAG_ALLOW_VENDORCHANGE flag.BOOLEAN DEPENDENCIES¶
Boolean Dependencies allow to build complex expressions from simple dependencies. While rpm does not support boolean expressions in dependencies and debian only allows an "OR" expression, libsolv allows one to arbitrary complex expressions. The following basic types are supported: REL_ORThe expression is true if either the first dependency or
the second one is true. This is useful for package dependencies like
“Requires”, where you can specify that either one of the
packages need to be installed.
REL_AND
The expression is true if both dependencies are true. The
packages fulfilling the dependencies may be different, i.e.
“Supplements: perl AND python” is true if both a package
providing perl and a package providing python are installed. The solver
currently only supports REL_AND in Supplements/Enhances dependencies, in other
types of dependencies it gets treated as REL_WITH.
REL_WITH
The expression is true if both dependencies are true and
are fulfilled by the same package. Thus “Supplements: perl AND
python” would only be true if a package is installed that provides both
dependencies (some kind of multi-language interpreter).
REL_COND
The expression is true if the first dependency is true or
the second dependency is false. Libsolv currently does not support this type
of dependency in the solver code.
Each sub-dependency of a boolean dependency can in turn be a boolean dependency,
so you can chain them to create complex dependencies.
NAMESPACE DEPENDENCIES¶
Namespace dependencies can be used to implement dependencies on attributes external to libsolv. An example would be a dependency on the language set by the user. This types of dependencies are usually only used for “Conflicts” or “Supplements” dependencies, as the underlying package manager does not know how to deal with them. If the library needs to evaluate a namespace dependency, it calls the namespace callback function set in the pool. The callback function can return a set of packages that “provide” the dependency. If the dependency is provided by the system, the returned set should consist of just the system solvable (Solvable Id 1). The returned set of packages must be returned as offset into the whatprovidesdata array. You can use the pool_queuetowhatprovides function to convert a queue into such an offset. To ease programming the callback function, the return values “0” and “1” are not interpreted as an offset. “0” means that no package is in the return set, “1” means that just the system solvable is in the set. The returned set is cached, so that for each namespace dependency the callback is just called once. If you need to flush the cache (maybe because the user has selected a different language), use the pool_flush_namespaceproviders() function.AUTHOR¶
Michael Schroeder <mls@suse.de>09/20/2013 | libsolv |