NAME

       libsolv-pool - Libsolv's pool object

PUBLIC ATTRIBUTES

       void *appdata
           A 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();

       Create a new instance of a pool.

           void pool_free(Pool *pool);

       Free a pool and all of the data it contains, e.g. the solvables, repositories, strings.

DEBUGGING AND ERROR REPORTING

   Constants
       SOLV_FATAL
           Report 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, ...);

       Report a message of the type type. You can filter debug messages by setting a debug mask.

           void pool_setdebuglevel(Pool *pool, int level);

       Set a predefined debug mask. A higher level generally means more bits in the mask are set,
       thus more messages are printed.

           void pool_setdebugmask(Pool *pool, int mask);

       Set the debug mask to filter debug messages.

           int pool_error(Pool *pool, int ret, const char *format, ...);

       Set the pool’s error string. The ret value is simply used as a return value of the
       function so that you can write code like return pool_error(...);. If the debug mask
       contains the SOLV_ERROR bit, pool_debug() is also called with the message and type
       SOLV_ERROR.

           extern char *pool_errstr(Pool *pool);

       Return the current error string stored in the pool. Like with the libc’s errno value, the
       string is only meaningful after a function returned an error.

           void pool_setdebugcallback(Pool *pool, void (*debugcallback)(Pool *, void *data, int type, const char *str), void *debugcallbackdata);

       Set a custom debug callback function. Instead of writing to stdout or stderr, the callback
       function will be called.

POOL CONFIGURATION

   Constants
       DISTTYPE_RPM
           Used 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
           int pool_setdisttype(Pool *pool, int disttype);

       Set the package type of your system. The disttype is used for example to define package
       comparison semantics. Libsolv’s default disttype should match the package manager of your
       system, so you only need to use this function if you want to use the library to solve
       packaging problems for different systems. The Function returns the old disttype on
       success, and -1 if the new disttype is not supported.

           int pool_set_flag(Pool *pool, int flag, int value);

       Set a flag to a new value. Returns the old value of the flag.

           int pool_get_flag(Pool *pool, int flag);

       Get the value of a pool flag. See the constants section about the meaning of the flags.

           void pool_set_rootdir(Pool *pool, const char *rootdir);

       Set a specific root directory. Some library functions support a flag that tells the
       function to prepend the rootdir to file and directory names.

           const char *pool_get_rootdir(Pool *pool);

       Return the current value of the root directory.

           char *pool_prepend_rootdir(Pool *pool, const char *dir);

       Prepend the root directory to the dir argument string. The returned string has been newly
       allocated and needs to be freed after use.

           char *pool_prepend_rootdir_tmp(Pool *pool, const char *dir);

       Same as pool_prepend_rootdir, but uses the pool’s temporary space for allocation.

           void pool_set_installed(Pool *pool, Repo *repo);

       Set which repository should be treated as the “installed” repository, i.e. the one that
       holds information about the installed packages.

           void pool_set_languages(Pool *pool, const char **languages, int nlanguages);

       Set the language of your system. The library provides lookup functions that return
       localized strings, for example for package descriptions. You can set an array of languages
       to provide a fallback mechanism if one language is not available.

           void pool_setarch(Pool *pool, const char *arch);

       Set the architecture of your system. The architecture is used to determine which packages
       are installable and which packages cannot be installed. The arch argument is normally the
       “machine” value of the “uname” system call.

           void pool_setarchpolicy(Pool *, const char *);

       Set the architecture policy for your system. This is the general version of pool_setarch
       (in fact pool_setarch calls pool_setarchpolicy internally). See the section about
       architecture policies for more information.

           void pool_addvendorclass(Pool *pool, const char **vendorclass);

       Add a new vendor equivalence class to the system. A vendor equivalence class defines if an
       installed package of one vendor can be replaced by a package coming from a different
       vendor. The vendorclass argument must be a NULL terminated array of strings. See the
       section about vendor policies for more information.

           void pool_setvendorclasses(Pool *pool, const char **vendorclasses);

       Set all allowed vendor equivalences. The vendorclasses argument must be an NULL terminated
       array consisting of all allowed classes concatenated. Each class itself must be NULL
       terminated, thus the last class ends with two NULL elements, one to finish the class and
       one to finish the list of classes.

           void pool_set_custom_vendorcheck(Pool *pool, int (*vendorcheck)(Pool *, Solvable *, Solvable *));

       Define a custom vendor check mechanism. You can use this if libsolv’s internal vendor
       equivalence class mechanism does not match your needs.

           void pool_setloadcallback(Pool *pool, int (*cb)(Pool *, Repodata *, void *), void *loadcbdata);

       Define a callback function that gets called when repository metadata needs to be loaded on
       demand. See the section about on demand loading in the libsolv-repodata manual.

           void pool_setnamespacecallback(Pool *pool, Id (*cb)(Pool *, void *, Id, Id), void *nscbdata);

       Define a callback function to implement custom namespace support. See the section about
       namespace dependencies.

ID POOL MANAGEMENT

   Constants
       ID_EMPTY
           The 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);

       Add a string to the pool of unified strings, returning the Id of the string. If create is
       zero, new strings will not be added to the pool, instead Id 0 is returned.

           Id pool_strn2id(Pool *pool, const char *str, unsigned int len, int create);

       Same as pool_str2id, but only len characters of the string are used. This can be used to
       add substrings to the pool.

           Id pool_rel2id(Pool *pool, Id name, Id evr, int flags, int create);

       Create a relational dependency from to other dependencies, name and evr, and a flag. See
       the REL_ constants for the supported flags. As with pool_str2id, create defines if new
       dependencies will get added or Id zero will be returned instead.

           Id pool_id2langid(Pool *pool, Id id, const char *lang, int create);

       Attach a language suffix to a string Id. This function can be used to create language
       keyname Ids from keynames, it is functional equivalent to converting the id argument to a
       string, adding a “:” character and the lang argument to the string and then converting the
       result back into an Id.

           const char *pool_id2str(const Pool *pool, Id id);

       Convert an Id back into a string. If the Id is a relational Id, the “name” part will be
       converted instead.

           const char *pool_id2rel(const Pool *pool, Id id);

       Return the relation string of a relational Id. Returns an empty string if the passed Id is
       not a relation.

           const char *pool_id2evr(const Pool *pool, Id id);

       Return the “evr” part of a relational Id as string. Returns an empty string if the passed
       Id is not a relation.

           const char *pool_dep2str(Pool *pool, Id id);

       Convert an Id back into a string. If the passed Id belongs to a relation, a string
       representing the relation is returned. Note that in that case the string is allocated on
       the pool’s temporary space.

           void pool_freeidhashes(Pool *pool);

       Free the hashes used to unify strings and relations. You can use this function to save
       memory if you know that you will no longer create new strings and relations.

SOLVABLE FUNCTIONS

           Solvable *pool_id2solvable(const Pool *pool, Id p);

       Convert a solvable Id into a pointer to the solvable data. Note that the pointer may
       become invalid if new solvables are created or old solvables deleted, because the array
       storing all solvables may get reallocated.

           const char *pool_solvid2str(Pool *pool, Id p);

       Return a string representing the solvable with the Id p. The string will be some canonical
       representation of the solvable, usually a combination of the name, the version, and the
       architecture.

           const char *pool_solvable2str(Pool *pool, Solvable *s);

       Same as pool_solvid2str, but instead of the Id, a pointer to the solvable is passed.

DEPENDENCY MATCHING

   Constants
       EVRCMP_COMPARE
           Compare 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);

       Compare two version Ids, return -1 if the first version is less then the second version, 0
       if they are identical, and 1 if the first version is bigger than the second one.

           int pool_evrcmp_str(const Pool *pool, const char *evr1, const char *evr2, int mode);

       Same as pool_evrcmp(), but uses strings instead of Ids.

           int pool_evrmatch(const Pool *pool, Id evrid, const char *epoch, const char *version, const char *release);

       Match a version Id against an epoch, a version and a release string. Passing NULL means
       that the part should match everything.

           int pool_match_dep(Pool *pool, Id d1, Id d2);

       Returns “1” if the dependency d1 (the provider) is matched by the dependency d2, otherwise
       “0” is returned. For two dependencies to match, both the “name” parts must match and the
       version range described by the “evr” parts must overlap.

           int pool_match_nevr(Pool *pool, Solvable *s, Id d);

       Like pool_match_dep, but the provider is the "self-provides" dependency of the Solvable s,
       i.e. the dependency “s→name = s→evr”.

WHATPROVIDES INDEX

           void pool_createwhatprovides(Pool *pool);

       Create a index that maps dependency Ids to sets of packages that provide the dependency.

           void pool_freewhatprovides(Pool *pool);

       Free the whatprovides index to save memory.

           Id pool_whatprovides(Pool *pool, Id d);

       Return an offset into the Pool’s whatprovidesdata array. The solvables with the Ids stored
       starting at that offset provide the dependency d. The solvable list is zero terminated.

           Id *pool_whatprovides_ptr(Pool *pool, Id d);

       Instead of returning the offset, return the pointer to the Ids stored at that offset. Note
       that this pointer has a very limit validity time, as any call that adds new values to the
       whatprovidesdata area may reallocate the array.

           Id pool_queuetowhatprovides(Pool *pool, Queue *q);

       Add the contents of the Queue q to the end of the whatprovidesdata array, returning the
       offset into the array.

           void pool_addfileprovides(Pool *pool);

       Some package managers like rpm allow dependencies on files contained in other packages. To
       allow libsolv to deal with those dependencies in an efficient way, you need to call the
       addfileprovides method after creating and reading all repositories. This method will scan
       all dependency for file names and than scan all packages for matching files. If a filename
       has been matched, it will be added to the provides list of the corresponding package.

           void pool_addfileprovides_queue(Pool *pool, Queue *idq, Queue *idqinst);

       Same as pool_addfileprovides, but the added Ids are returned in two Queues, idq for all
       repositories except the one containing the “installed” packages, idqinst for the latter
       one. This information can be stored in the meta section of the repositories to speed up
       the next time the repository is loaded and addfileprovides is called

           void pool_flush_namespaceproviders(Pool *pool, Id ns, Id evr);

       Clear the cache of the providers for namespace dependencies matching namespace ns. If the
       evr argument is non-zero, the namespace dependency for exactly that dependency is cleared,
       otherwise all matching namespace dependencies are cleared. See the section about Namespace
       dependencies for further information.

           void pool_add_fileconflicts_deps(Pool *pool, Queue *conflicts);

       Some package managers like rpm report conflicts when a package installation overwrites a
       file of another installed package with different content. As file content information is
       not stored in the repository metadata, those conflicts can only be detected after the
       packages are downloaded. Libsolv provides a function to check for such conflicts,
       pool_findfileconflicts(). If conflicts are found, they can be added as special
       REL_FILECONFLICT provides dependencies, so that the solver will know about the conflict
       when it is re-run.

UTILITY FUNCTIONS

           char *pool_alloctmpspace(Pool *pool, int len);

       Allocate space on the pool’s temporary space area. This space has a limited lifetime, it
       will be automatically freed after a fixed amount (currently 16) of other
       pool_alloctmpspace() calls are done.

           void pool_freetmpspace(Pool *pool, const char *space);

       Give the space allocated with pool_alloctmpspace back to the system. You do not have to
       use this function, as the space is automatically reclaimed, but it can be useful to extend
       the lifetime of other pointers to the pool’s temporary space area.

           const char *pool_bin2hex(Pool *pool, const unsigned char *buf, int len);

       Convert some binary data to hexadecimal, returning a string allocated in the pool’s
       temporary space area.

           char *pool_tmpjoin(Pool *pool, const char *str1, const char *str2, const char *str3);

       Join three strings and return the result in the pool’s temporary space area. You can use
       NULL arguments if you just want to join less strings.

           char *pool_tmpappend(Pool *pool, const char *str1, const char *str2, const char *str3);

       Like pool_tmpjoin(), but if the first argument is the last allocated space in the pool’s
       temporary space area, it will be replaced with the result of the join and no new temporary
       space slot will be used. Thus you can join more then three strings by a combination of one
       pool_tmpjoin() and multiple pool_tmpappend() calls. Note that the str1 pointer is no
       longer usable after the call.

DATA LOOKUP

   Constants
       SOLVID_POS
           Use 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);

       Return the string value stored under the attribute keyname in solvable solvid.

           unsigned long long pool_lookup_num(Pool *pool, Id solvid, Id keyname, unsigned long long notfound);

       Return the 64bit unsigned number stored under the attribute keyname in solvable solvid. If
       no such number is found, the value of the notfound argument is returned instead.

           Id pool_lookup_id(Pool *pool, Id solvid, Id keyname);

       Return the Id stored under the attribute keyname in solvable solvid.

           int pool_lookup_idarray(Pool *pool, Id solvid, Id keyname, Queue *q);

       Fill the queue q with the content of the Id array stored under the attribute keyname in
       solvable solvid. Returns “1” if an array was found, otherwise the queue will be empty and
       “0” will be returned.

           int pool_lookup_void(Pool *pool, Id solvid, Id keyname);

       Returns “1” if a void value is stored under the attribute keyname in solvable solvid,
       otherwise “0”.

           const char *pool_lookup_checksum(Pool *pool, Id solvid, Id keyname, Id *typep);

       Return the checksum that is stored under the attribute keyname in solvable solvid. The
       type of the checksum will be returned over the typep pointer. If no such checksum is
       found, NULL will be returned and the type will be set to zero. Note that the result is
       stored in the Pool’s temporary space area.

           const unsigned char *pool_lookup_bin_checksum(Pool *pool, Id solvid, Id keyname, Id *typep);

       Return the checksum that is stored under the attribute keyname in solvable solvid. Returns
       the checksum as binary data, you can use the returned type to calculate the length of the
       checksum. No temporary space area is needed.

           const char *pool_lookup_deltalocation(Pool *pool, Id solvid, unsigned int *medianrp);

       This is a utility lookup function to return the delta location for a delta rpm. As
       solvables cannot store deltas, you have to use SOLVID_POS as argument and set the Pool’s
       datapos pointer to point to valid delta rpm data.

           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);

       Perform a search on all data stored in the pool. You can limit the search area by using
       the solvid and keyname arguments. The values can be optionally matched against the match
       argument, use NULL if you do not want this matching. See the Dataiterator manpage about
       the possible matches modes and the flags argument. For all (matching) values, the callback
       function is called with the cbdata callback argument and the data describing the value.

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);

       Convert a job into a string. Useful for debugging purposes. The flagmask can be used to
       mask the flags of the job, use “0” if you do not want to see such flags, “-1” to see all
       flags, or a combination of the flags you want to see.

           void pool_job2solvables(Pool *pool, Queue *pkgs, Id how, Id what);

       Return a list of solvables that the specified job selects.

           int pool_isemptyupdatejob(Pool *pool, Id how, Id what);

       Return “1” if the job is an update job that does not work with any installed package, i.e.
       the job is basically a no-op. You can use this to turn no-op update jobs into install jobs
       (as done by package managers like “zypper”).

           const char *pool_selection2str(Pool *pool, Queue *selection, Id flagmask);

       Convert a selection into a string. Useful for debugging purposes. See the pool_job2str()
       function for the flagmask argument.

ODDS AND ENDS

           void pool_freeallrepos(Pool *pool, int reuseids);

       Free all repos from the pool (including all solvables). If reuseids is true, all Ids of
       the solvables are free to be reused the next time solvables are created.

           void pool_clear_pos(Pool *pool);

       Clear the data position stored in the 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 arbitrary complex expressions. The following basic types are
       supported:

       REL_OR
           The 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>