9 libsolv-pool - Libsolv's pool object
16 A no-purpose pointer free to use for the library user. Freeing the pool
17 simply discards the pointer.
20 The pool of unified strings.
23 The pool of unified relation dependencies.
26 Number of allocated relation dependencies.
29 The array of repository pointers, indexed by repository Id.
32 Number of allocated repository array elements, i.e. the size
36 Number of used (i.e. non-zero) repository array elements.
39 Pointer to the repo holding the installed packages. You are free to read
40 this attribute, but you should use pool_set_installed() if you want to
43 *Solvable *solvables*::
44 The array of Solvable objects.
47 Number of Solvable objects, i.e. the size of the solvables array. Note
48 that the array may contain freed solvables, in that case the repo pointer
49 of the solvable will be zero.
52 The distribution type of your system, e.g. DISTTYPE_DEB. You are free to
53 read this attribute, but you should use pool_setdisttype() if you want to
56 *Id *whatprovidesdata*::
57 Multi-purpose Id storage holding zero terminated arrays of Ids.
58 pool_whatprovides() returns an offset into this data.
61 Optional bitmap that can make the library ignore solvables. If a bitmap is
62 set, only solvables that have a set bit in the bitmap at their Id are
66 A mask that defines which debug events should be reported.
67 pool_setdebuglevel() sets this mask.
70 An object storing some position in the repository data. Functions like
71 dataiterator_set_pos() set this object, accessing data with a pseudo
72 solvable Id of SOLVID_POS uses it.
75 A queue where fixed solver jobs can be stored. This jobs are automatically
76 added when solver_solve() is called, they are useful to store configuration
77 data like which packages should be multiversion installed.
79 Creation and Destruction
80 ------------------------
84 Create a new instance of a pool.
86 void pool_free(Pool *pool);
88 Free a pool and all of the data it contains, e.g. the solvables,
89 repositories, strings.
92 Debugging and error reporting
93 -----------------------------
98 Report the error and call ``exit(1)'' afterwards. You cannot mask this
99 level. Reports to stderr instead of stdout.
102 Used to report errors. Reports to stderr instead of stdout.
105 Used to report warnings.
108 Used to report statistical data.
110 *SOLV_DEBUG_RULE_CREATION*::
111 Used to report information about the solver's creation of rules.
113 *SOLV_DEBUG_PROPAGATE*::
114 Used to report information about the solver's unit rule propagation
117 *SOLV_DEBUG_ANALYZE*::
118 Used to report information about the solver's learnt rule generation
121 *SOLV_DEBUG_UNSOLVABLE*::
122 Used to report information about the solver dealing with conflicting
125 *SOLV_DEBUG_SOLUTIONS*::
126 Used to report information about the solver creating solutions to solve
129 *SOLV_DEBUG_POLICY*::
130 Used to report information about the solver searching for an optimal
133 *SOLV_DEBUG_RESULT*::
134 Used by the debug functions to output results.
137 Used to report information about the job rule generation process.
139 *SOLV_DEBUG_SOLVER*::
140 Used to report information about what the solver is currently
143 *SOLV_DEBUG_TRANSACTION*::
144 Used to report information about the transaction generation and
147 *SOLV_DEBUG_TO_STDERR*::
148 Write debug messages to stderr instead of stdout.
152 void pool_debug(Pool *pool, int type, const char *format, ...);
154 Report a message of the type _type_. You can filter debug messages by
155 setting a debug mask.
157 void pool_setdebuglevel(Pool *pool, int level);
159 Set a predefined debug mask. A higher level generally means more bits in
160 the mask are set, thus more messages are printed.
162 void pool_setdebugmask(Pool *pool, int mask);
164 Set the debug mask to filter debug messages.
166 int pool_error(Pool *pool, int ret, const char *format, ...);
168 Set the pool's error string. The _ret_ value is simply used as a
169 return value of the function so that you can write code like
170 +return pool_error(...);+. If the debug mask contains the *SOLV_ERROR*
171 bit, pool_debug() is also called with the message and type *SOLV_ERROR*.
173 extern char *pool_errstr(Pool *pool);
175 Return the current error string stored in the pool. Like with the libc's
176 errno value, the string is only meaningful after a function returned an
179 void pool_setdebugcallback(Pool *pool, void (*debugcallback)(Pool *, void *data, int type, const char *str), void *debugcallbackdata);
181 Set a custom debug callback function. Instead of writing to stdout or
182 stderr, the callback function will be called.
191 Used for systems which use rpm as low level package manager.
194 Used for systems which use dpkg as low level package manager.
197 Used for systems which use the arch linux package manager.
200 Used for systems which use haiku packages.
202 *POOL_FLAG_PROMOTEEPOCH*::
203 Promote the epoch of the providing dependency to the requesting
204 dependency if it does not contain an epoch. Used at some time
205 in old rpm versions, modern systems should never need this.
207 *POOL_FLAG_FORBIDSELFCONFLICTS*::
208 Disallow the installation of packages that conflict with themselves.
209 Debian always allows self-conflicting packages, rpm used to forbid
210 them but switched to also allowing them recently.
212 *POOL_FLAG_OBSOLETEUSESPROVIDES*::
213 Make obsolete type dependency match against provides instead of
214 just the name and version of packages. Very old versions of rpm
215 used the name/version, then it got switched to provides and later
216 switched back again to just name/version.
218 *POOL_FLAG_IMPLICITOBSOLETEUSESPROVIDES*::
219 An implicit obsoletes is the internal mechanism to remove the
220 old package on an update. The default is to remove all packages
221 with the same name, rpm-5 switched to also removing packages
222 providing the same name.
224 *POOL_FLAG_OBSOLETEUSESCOLORS*::
225 Rpm's multilib implementation (used in RedHat and Fedora)
226 distinguishes between 32bit and 64bit packages (the terminology
227 is that they have a different color). If obsoleteusescolors is
228 set, packages with different colors will not obsolete each other.
230 *POOL_FLAG_IMPLICITOBSOLETEUSESCOLORS*::
231 Same as POOL_FLAG_OBSOLETEUSESCOLORS, but used to find out if
232 packages of the same name can be installed in parallel. For
233 current Fedora systems, POOL_FLAG_OBSOLETEUSESCOLORS should be
234 false and POOL_FLAG_IMPLICITOBSOLETEUSESCOLORS should be true
235 (this is the default if FEDORA is defined when libsolv is
238 *POOL_FLAG_NOINSTALLEDOBSOLETES*::
239 New versions of rpm consider the obsoletes of installed packages
240 when checking for dependency, thus you may not install a package
241 that is obsoleted by some other installed package, unless you
242 also erase the other package.
244 *POOL_FLAG_HAVEDISTEPOCH*::
245 Mandriva added a new field called distepoch that gets checked in
246 version comparison if the epoch/version/release of two packages
249 *POOL_FLAG_NOOBSOLETESMULTIVERSION*::
250 If a package is installed in multiversionmode, rpm used to ignore
251 both the implicit obsoletes and the obsolete dependency of a
252 package. This was changed to ignoring just the implicit obsoletes,
253 thus you may install multiple versions of the same name, but
254 obsoleted packages still get removed.
256 *POOL_FLAG_ADDFILEPROVIDESFILTERED*::
257 Make the addfileprovides method only add files from the standard
258 locations (i.e. the ``bin'' and ``etc'' directories). This is
259 useful if you have only few packages that use non-standard file
260 dependencies, but you still want the fast speed that addfileprovides()
265 int pool_setdisttype(Pool *pool, int disttype);
267 Set the package type of your system. The disttype is used for example
268 to define package comparison semantics. Libsolv's default disttype
269 should match the package manager of your system, so you only need to
270 use this function if you want to use the library to solve packaging
271 problems for different systems. The Function returns the old
272 disttype on success, and -1 if the new disttype is not supported.
273 Note that any pool_setarch and pool_setarchpolicy calls need to
274 come after the pool_setdisttype call, as they make use of the
275 noarch/any/all architecture id.
277 int pool_set_flag(Pool *pool, int flag, int value);
279 Set a flag to a new value. Returns the old value of the flag.
281 int pool_get_flag(Pool *pool, int flag);
283 Get the value of a pool flag. See the constants section about the meaning
286 void pool_set_rootdir(Pool *pool, const char *rootdir);
288 Set a specific root directory. Some library functions support a flag that
289 tells the function to prepend the rootdir to file and directory names.
291 const char *pool_get_rootdir(Pool *pool);
293 Return the current value of the root directory.
295 char *pool_prepend_rootdir(Pool *pool, const char *dir);
297 Prepend the root directory to the _dir_ argument string. The returned
298 string has been newly allocated and needs to be freed after use.
300 char *pool_prepend_rootdir_tmp(Pool *pool, const char *dir);
302 Same as pool_prepend_rootdir, but uses the pool's temporary space for
305 void pool_set_installed(Pool *pool, Repo *repo);
307 Set which repository should be treated as the ``installed'' repository,
308 i.e. the one that holds information about the installed packages.
310 void pool_set_languages(Pool *pool, const char **languages, int nlanguages);
312 Set the language of your system. The library provides lookup functions that
313 return localized strings, for example for package descriptions. You can
314 set an array of languages to provide a fallback mechanism if one language
317 void pool_setarch(Pool *pool, const char *arch);
319 Set the architecture of your system. The architecture is used to determine
320 which packages are installable and which packages cannot be installed.
321 The _arch_ argument is normally the ``machine'' value of the ``uname''
324 void pool_setarchpolicy(Pool *, const char *);
326 Set the architecture policy for your system. This is the general version
327 of pool_setarch (in fact pool_setarch calls pool_setarchpolicy internally).
328 See the section about architecture policies for more information.
330 void pool_addvendorclass(Pool *pool, const char **vendorclass);
332 Add a new vendor equivalence class to the system. A vendor equivalence class
333 defines if an installed package of one vendor can be replaced by a package
334 coming from a different vendor. The _vendorclass_ argument must be a
335 NULL terminated array of strings. See the section about vendor policies for
338 void pool_setvendorclasses(Pool *pool, const char **vendorclasses);
340 Set all allowed vendor equivalences. The vendorclasses argument must be an
341 NULL terminated array consisting of all allowed classes concatenated.
342 Each class itself must be NULL terminated, thus the last class ends with
343 two NULL elements, one to finish the class and one to finish the list
346 void pool_set_custom_vendorcheck(Pool *pool, int (*vendorcheck)(Pool *, Solvable *, Solvable *));
348 Define a custom vendor check mechanism. You can use this if libsolv's
349 internal vendor equivalence class mechanism does not match your needs.
351 void pool_setloadcallback(Pool *pool, int (*cb)(Pool *, Repodata *, void *), void *loadcbdata);
353 Define a callback function that gets called when repository metadata needs
354 to be loaded on demand. See the section about on demand loading in the
355 libsolv-repodata manual.
357 void pool_setnamespacecallback(Pool *pool, Id (*cb)(Pool *, void *, Id, Id), void *nscbdata);
359 Define a callback function to implement custom namespace support. See the
360 section about namespace dependencies.
368 The Id of the empty string, it is always Id 1.
371 Represents a ``<'' relation.
374 Represents a ``='' relation.
377 Represents a ``>'' relation. You can use combinations of REL_GT, REL_EQ,
378 and REL_LT or-ed together to create any relation you like.
381 A boolean AND operation, the ``name'' and ``evr'' parts of the relation can
382 be two sub-dependencies. Packages must match both parts of the dependency.
385 A boolean OR operation, the ``name'' and ``evr'' parts of the relation can
386 be two sub-dependencies. Packages can match any part of the dependency.
389 Like REL_AND, but packages must match both dependencies simultaneously. See
390 the section about boolean dependencies about more information.
393 A special namespace relation. See the section about namespace dependencies
394 for more information.
397 An architecture filter dependency. The ``name'' part of the relation is a
398 sub-dependency, the ``evr'' part is the Id of an architecture that the
399 matching packages must have (note that this is an exact match ignoring
400 architecture policies).
403 An internal file conflict dependency used to represent file conflicts. See
404 the pool_add_fileconflicts_deps() function.
407 A conditional dependency, the ``name'' sub-dependency is only considered if
408 the ``evr'' sub-dependency is fulfilled. See the section about boolean
409 dependencies about more information.
412 A conditional dependency, the ``name'' sub-dependency is only considered if
413 the ``evr'' sub-dependency is not fulfilled. See the section about boolean
414 dependencies about more information.
417 A compat dependency used in Haiku to represent version ranges. The
418 ``name'' part is the actual version, the ``evr'' part is the backwards
419 compatibility version.
422 A pseudo dependency that limits the solvables to a specific kind.
423 The kind is expected to be a prefix of the solvable name, e.g.
424 ``patch:foo'' would be of kind ``patch''. ``REL_KIND'' is only
425 supported in the selection functions.
428 A debian multiarch annotation. The most common value for the ``evr''
432 The else part of a ``REL_COND'' or ``REL_UNLESS'' dependency. See the
433 section about boolean dependencies.
436 An illegal dependency. This is useful to encode dependency parse errors.
439 Id pool_str2id(Pool *pool, const char *str, int create);
441 Add a string to the pool of unified strings, returning the Id of the string.
442 If _create_ is zero, new strings will not be added to the pool, instead
445 Id pool_strn2id(Pool *pool, const char *str, unsigned int len, int create);
447 Same as pool_str2id, but only _len_ characters of the string are used. This
448 can be used to add substrings to the pool.
450 Id pool_rel2id(Pool *pool, Id name, Id evr, int flags, int create);
452 Create a relational dependency from to other dependencies, _name_ and _evr_,
453 and a _flag_. See the *REL_* constants for the supported flags. As with
454 pool_str2id, _create_ defines if new dependencies will get added or Id zero
455 will be returned instead.
457 Id pool_id2langid(Pool *pool, Id id, const char *lang, int create);
459 Attach a language suffix to a string Id. This function can be used to
460 create language keyname Ids from keynames, it is functional equivalent
461 to converting the _id_ argument to a string, adding a ``:'' character
462 and the _lang_ argument to the string and then converting the result back
465 const char *pool_id2str(const Pool *pool, Id id);
467 Convert an Id back into a string. If the Id is a relational Id, the
468 ``name'' part will be converted instead.
470 const char *pool_id2rel(const Pool *pool, Id id);
472 Return the relation string of a relational Id. Returns an empty string if
473 the passed Id is not a relation.
475 const char *pool_id2evr(const Pool *pool, Id id);
477 Return the ``evr'' part of a relational Id as string. Returns an empty
478 string if the passed Id is not a relation.
480 const char *pool_dep2str(Pool *pool, Id id);
482 Convert an Id back into a string. If the passed Id belongs to a relation,
483 a string representing the relation is returned. Note that in that case
484 the string is allocated on the pool's temporary space.
486 void pool_freeidhashes(Pool *pool);
488 Free the hashes used to unify strings and relations. You can use this
489 function to save memory if you know that you will no longer create new
490 strings and relations.
496 Solvable *pool_id2solvable(const Pool *pool, Id p);
498 Convert a solvable Id into a pointer to the solvable data. Note that the
499 pointer may become invalid if new solvables are created or old solvables
500 deleted, because the array storing all solvables may get reallocated.
502 Id pool_solvable2id(const Pool *pool, Solvable *s);
504 Convert a pointer to the solvable data into a solvable Id.
506 const char *pool_solvid2str(Pool *pool, Id p);
508 Return a string representing the solvable with the Id _p_. The string will
509 be some canonical representation of the solvable, usually a combination of
510 the name, the version, and the architecture.
512 const char *pool_solvable2str(Pool *pool, Solvable *s);
514 Same as pool_solvid2str, but instead of the Id, a pointer to the solvable
523 Compare all parts of the version, treat missing parts as empty strings.
525 *EVRCMP_MATCH_RELEASE*::
526 A special mode for rpm version string matching. If a version misses a
527 release part, it matches all releases. In that case the special values
528 ``-2'' and ``2'' are returned, depending on which of the two versions
529 did not have a release part.
532 A generic match, missing parts always match.
534 *EVRCMP_COMPARE_EVONLY*::
535 Only compare the epoch and the version parts, ignore the release part.
538 int pool_evrcmp(const Pool *pool, Id evr1id, Id evr2id, int mode);
540 Compare two version Ids, return -1 if the first version is less than the
541 second version, 0 if they are identical, and 1 if the first version is
542 bigger than the second one.
544 int pool_evrcmp_str(const Pool *pool, const char *evr1, const char *evr2, int mode);
546 Same as pool_evrcmp(), but uses strings instead of Ids.
548 int pool_evrmatch(const Pool *pool, Id evrid, const char *epoch, const char *version, const char *release);
550 Match a version Id against an epoch, a version and a release string. Passing
551 NULL means that the part should match everything.
553 int pool_match_dep(Pool *pool, Id d1, Id d2);
555 Returns ``1'' if the dependency _d1_ (the provider) is matched by the
556 dependency _d2_, otherwise ``0'' is returned. For two dependencies to
557 match, both the ``name'' parts must match and the version range described
558 by the ``evr'' parts must overlap.
560 int pool_match_nevr(Pool *pool, Solvable *s, Id d);
562 Like pool_match_dep, but the provider is the "self-provides" dependency
563 of the Solvable _s_, i.e. the dependency ``s->name = s->evr''.
568 void pool_createwhatprovides(Pool *pool);
570 Create an index that maps dependency Ids to sets of packages that provide the
573 void pool_freewhatprovides(Pool *pool);
575 Free the whatprovides index to save memory.
577 Id pool_whatprovides(Pool *pool, Id d);
579 Return an offset into the Pool's whatprovidesdata array. The solvables with
580 the Ids stored starting at that offset provide the dependency _d_. The
581 solvable list is zero terminated.
583 Id *pool_whatprovides_ptr(Pool *pool, Id d);
585 Instead of returning the offset, return the pointer to the Ids stored at
586 that offset. Note that this pointer has a very limit validity time, as any
587 call that adds new values to the whatprovidesdata area may reallocate the
590 Id pool_queuetowhatprovides(Pool *pool, Queue *q);
592 Add the contents of the Queue _q_ to the end of the whatprovidesdata array,
593 returning the offset into the array.
595 void pool_addfileprovides(Pool *pool);
597 Some package managers like rpm allow dependencies on files contained in
598 other packages. To allow libsolv to deal with those dependencies in an
599 efficient way, you need to call the addfileprovides method after creating
600 and reading all repositories. This method will scan all dependency for file
601 names and then scan all packages for matching files. If a filename has been
602 matched, it will be added to the provides list of the corresponding
605 void pool_addfileprovides_queue(Pool *pool, Queue *idq, Queue *idqinst);
607 Same as pool_addfileprovides, but the added Ids are returned in two Queues,
608 _idq_ for all repositories except the one containing the ``installed''
609 packages, _idqinst_ for the latter one. This information can be stored in
610 the meta section of the repositories to speed up the next time the
611 repository is loaded and addfileprovides is called
613 void pool_set_whatprovides(pool, Id id, Id offset);
615 Manually set an entry in the whatprovides index. You'll never do this for
616 package dependencies, as those entries are created by calling the
617 pool_createwhatprovides() function. But this function is useful for
618 namespace provides if you do not want to use a namespace callback to
619 lazily set the provides. The offset argument is a offset in the
620 whatprovides array, thus you can use ``1'' as a false value and ``2''
623 void pool_flush_namespaceproviders(Pool *pool, Id ns, Id evr);
625 Clear the cache of the providers for namespace dependencies matching
626 namespace _ns_. If the _evr_ argument is non-zero, the namespace dependency
627 for exactly that dependency is cleared, otherwise all matching namespace
628 dependencies are cleared. See the section about Namespace dependencies
629 for further information.
631 void pool_add_fileconflicts_deps(Pool *pool, Queue *conflicts);
633 Some package managers like rpm report conflicts when a package installation
634 overwrites a file of another installed package with different content. As
635 file content information is not stored in the repository metadata, those
636 conflicts can only be detected after the packages are downloaded. Libsolv
637 provides a function to check for such conflicts, pool_findfileconflicts().
638 If conflicts are found, they can be added as special *REL_FILECONFLICT*
639 provides dependencies, so that the solver will know about the conflict when
645 char *pool_alloctmpspace(Pool *pool, int len);
647 Allocate space on the pool's temporary space area. This space has a limited
648 lifetime, it will be automatically freed after a fixed amount (currently
649 16) of other pool_alloctmpspace() calls are done.
651 void pool_freetmpspace(Pool *pool, const char *space);
653 Give the space allocated with pool_alloctmpspace back to the system. You
654 do not have to use this function, as the space is automatically reclaimed,
655 but it can be useful to extend the lifetime of other pointers to the pool's
656 temporary space area.
658 const char *pool_bin2hex(Pool *pool, const unsigned char *buf, int len);
660 Convert some binary data to hexadecimal, returning a string allocated in
661 the pool's temporary space area.
663 char *pool_tmpjoin(Pool *pool, const char *str1, const char *str2, const char *str3);
665 Join three strings and return the result in the pool's temporary space
666 area. You can use NULL arguments if you just want to join less strings.
668 char *pool_tmpappend(Pool *pool, const char *str1, const char *str2, const char *str3);
670 Like pool_tmpjoin(), but if the first argument is the last allocated space
671 in the pool's temporary space area, it will be replaced with the result of
672 the join and no new temporary space slot will be used. Thus you can join
673 more than three strings by a combination of one pool_tmpjoin() and multiple
674 pool_tmpappend() calls. Note that the _str1_ pointer is no longer usable
683 Use the data position stored in the pool for the lookup instead of looking
684 up the data of a solvable.
687 Use the data stored in the meta section of a repository (or repodata
688 area) instead of looking up the data of a solvable. This constant does
689 not work for the pool's lookup functions, use it for the repo's or
690 repodata's lookup functions instead. It's just listed for completeness.
693 const char *pool_lookup_str(Pool *pool, Id solvid, Id keyname);
695 Return the string value stored under the attribute _keyname_ in solvable
698 unsigned long long pool_lookup_num(Pool *pool, Id solvid, Id keyname, unsigned long long notfound);
700 Return the 64bit unsigned number stored under the attribute _keyname_ in
701 solvable _solvid_. If no such number is found, the value of the _notfound_
702 argument is returned instead.
704 Id pool_lookup_id(Pool *pool, Id solvid, Id keyname);
706 Return the Id stored under the attribute _keyname_ in solvable _solvid_.
708 int pool_lookup_idarray(Pool *pool, Id solvid, Id keyname, Queue *q);
710 Fill the queue _q_ with the content of the Id array stored under the
711 attribute _keyname_ in solvable _solvid_. Returns ``1'' if an array was
712 found, otherwise the queue will be empty and ``0'' will be returned.
714 int pool_lookup_void(Pool *pool, Id solvid, Id keyname);
716 Returns ``1'' if a void value is stored under the attribute _keyname_ in
717 solvable _solvid_, otherwise ``0''.
719 const char *pool_lookup_checksum(Pool *pool, Id solvid, Id keyname, Id *typep);
721 Return the checksum that is stored under the attribute _keyname_ in
722 solvable _solvid_. The type of the checksum will be returned over the
723 _typep_ pointer. If no such checksum is found, NULL will be returned and
724 the type will be set to zero. Note that the result is stored in the Pool's
725 temporary space area.
727 const unsigned char *pool_lookup_bin_checksum(Pool *pool, Id solvid, Id keyname, Id *typep);
729 Return the checksum that is stored under the attribute _keyname_ in
730 solvable _solvid_. Returns the checksum as binary data, you can use the
731 returned type to calculate the length of the checksum. No temporary space
734 const char *pool_lookup_deltalocation(Pool *pool, Id solvid, unsigned int *medianrp);
736 This is a utility lookup function to return the delta location for a delta
737 rpm. As solvables cannot store deltas, you have to use SOLVID_POS as
738 argument and set the Pool's datapos pointer to point to valid delta rpm
741 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);
743 Perform a search on all data stored in the pool. You can limit the search
744 area by using the _solvid_ and _keyname_ arguments. The values can be
745 optionally matched against the _match_ argument, use NULL if you do not
746 want this matching. See the Dataiterator manpage about the possible matches
747 modes and the _flags_ argument. For all (matching) values, the callback
748 function is called with the _cbdata_ callback argument and the data
749 describing the value.
752 Job and Selection functions
753 ---------------------------
754 A Job consists of two Ids, _how_ and _what_. The _how_ part describes the
755 action, the job flags, and the selection method while the _what_ part is
756 in input for the selection. A Selection is a queue consisting of multiple
757 jobs (thus the number of elements in the queue must be a multiple of two).
758 See the Solver manpage for more information about jobs.
760 const char *pool_job2str(Pool *pool, Id how, Id what, Id flagmask);
762 Convert a job into a string. Useful for debugging purposes. The _flagmask_
763 can be used to mask the flags of the job, use ``0'' if you do not want to
764 see such flags, ``-1'' to see all flags, or a combination of the flags
767 void pool_job2solvables(Pool *pool, Queue *pkgs, Id how, Id what);
769 Return a list of solvables that the specified job selects.
771 int pool_isemptyupdatejob(Pool *pool, Id how, Id what);
773 Return ``1'' if the job is an update job that does not work with any
774 installed package, i.e. the job is basically a no-op. You can use this
775 to turn no-op update jobs into install jobs (as done by package managers
778 const char *pool_selection2str(Pool *pool, Queue *selection, Id flagmask);
780 Convert a selection into a string. Useful for debugging purposes. See the
781 pool_job2str() function for the _flagmask_ argument.
786 void pool_freeallrepos(Pool *pool, int reuseids);
788 Free all repos from the pool (including all solvables). If _reuseids_ is
789 true, all Ids of the solvables are free to be reused the next time
790 solvables are created.
792 void pool_clear_pos(Pool *pool);
794 Clear the data position stored in the pool.
797 Architecture Policies
798 ---------------------
799 An architecture policy defines a list of architectures that can be
800 installed on the system, and also the relationship between them (i.e. the
801 ordering). Architectures can be delimited with three different characters:
804 No relationship between the architectures. A package of one architecture
805 can not be replaced with one of the other architecture.
808 The first architecture is better than the second one. An installed package
809 of the second architecture may be replaced with one from the first
810 architecture and vice versa. The solver will select the better architecture
811 if the versions are the same.
814 The two architectures are freely exchangeable. Used to define aliases
817 An example would be \'+x86_64:i686=athlon>i586+'. This means that x86_64
818 packages can only be replaced by other x86_64 packages, i686 packages
819 can be replaced by i686 and i586 packages (but i686 packages will be
820 preferred) and athlon is another name for the i686 architecture.
822 You can turn off the architecture replacement checks with the Solver's
823 SOLVER_FLAG_ALLOW_ARCHCHANGE flag.
827 Different vendors often compile packages with different features, so
828 Libsolv only replace installed packages of one vendor with packages coming
829 from the same vendor. Also, while the version of a package is normally
830 defined by the upstream project, the release part of the version is
831 set by the vendor's package maintainer, so it's not meaningful to
832 do version comparisons for packages coming from different vendors.
834 Vendor in this case means the SOLVABLE_VENDOR string stored in each
835 solvable. Sometimes a vendor changes names, or multiple vendors form a
836 group that coordinate their package building, so libsolv offers a way
837 to define that a group of vendors are compatible. You do that be
838 defining vendor equivalence classes, packages from a vendor from
839 one class may be replaced with packages from all the other vendors
842 There can be multiple equivalence classes, the set of allowed vendor
843 changes for an installed package is calculated by building the union
844 of all of the equivalence classes the vendor of the installed package
847 You can turn off the vendor replacement checks with the Solver's
848 SOLVER_FLAG_ALLOW_VENDORCHANGE flag.
853 Boolean Dependencies allow to build complex expressions from simple
854 dependencies. Note that depending on the package manager only a subset
855 of those may be useful. For example, debian currently only allows
859 The expression is true if either the first dependency or the second
860 one is true. This is useful for package dependencies like ``Requires'',
861 where you can specify that either one of the packages need to be
865 The expression is true if both dependencies are true. The packages
866 fulfilling the dependencies may be different, i.e.
867 ``Supplements: perl REL_AND python'' is true if both a package providing
868 perl and a package providing python are installed.
871 The expression is true if both dependencies are true and are fulfilled by
872 the same package. Thus ``Supplements: perl REL_WITH python'' would only be true
873 if a package is installed that provides both dependencies (some kind
874 of multi-language interpreter).
877 The expression is true if the first dependency is true or the second
878 dependency is false. ``A REL_COND B'' is equivalent to
879 ``A REL_OR (NOT B)'' (except that libsolv does not expose ``NOT'').
882 The expression is true if the first dependency is true and the second
883 dependency is false. ``A REL_UNLESS B'' is equivalent to
884 ``A REL_AND (NOT B)'' (except that libsolv does not expose ``NOT'').
887 The ``else'' part of a ``REL_COND'' or ``REL_UNLESS'' dependency.
888 It has to be directly in the evr part of the condition,
889 e.g. ``foo REL_COND (bar REL_ELSE baz)''.
890 For ``REL_COND'' this is equivalent to writing
891 ``(foo REL_COND bar) REL_AND (bar REL_OR baz)''.
892 For ``REL_UNLESS'' this is equivalent to writing
893 ``(foo REL_UNLESS bar) REL_OR (bar REL_AND baz)''.
895 Each sub-dependency of a boolean dependency can in turn be a boolean
896 dependency, so you can chain them to create complex dependencies.
899 Namespace Dependencies
900 ----------------------
901 Namespace dependencies can be used to implement dependencies on
902 attributes external to libsolv. An example would be a dependency
903 on the language set by the user. This types of dependencies are
904 usually only used for ``Conflicts'' or ``Supplements'' dependencies,
905 as the underlying package manager does not know how to deal with
908 If the library needs to evaluate a namespace dependency, it calls
909 the namespace callback function set in the pool. The callback
910 function can return a set of packages that ``provide'' the
911 dependency. If the dependency is provided by the system, the
912 returned set should consist of just the system solvable (Solvable
915 The returned set of packages must be returned as offset into
916 the whatprovidesdata array. You can use the pool_queuetowhatprovides
917 function to convert a queue into such an offset. To ease programming
918 the callback function, the return values ``0'' and ``1'' are not
919 interpreted as an offset. ``0'' means that no package is in the
920 return set, ``1'' means that just the system solvable is in the set.
922 The returned set is cached, so that for each namespace dependency
923 the callback is just called once. If you need to flush the cache (maybe
924 because the user has selected a different language), use the
925 pool_flush_namespaceproviders() function.
930 Michael Schroeder <mls@suse.de>