distinguishes between 32bit and 64bit packages (the terminology
is that they have a different color). If obsolteusescolors is
set, packages with different colors will not obsolete each other.
- This is also true for implicit obsoletes, thus you can install
- both the 32bit and the 64bit version of a package with the
- same name.
+
+*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
Add a raw element to the selection. Check the Job class for information about
the how and what parameters.
- Job *jobs(int action)
+ Job **jobs(int action)
my @jobs = $sel->jobs($action);
jobs = sel.jobs(action)
jobs = sel.jobs(action)
to the ``how'' part of the job, it describes the type of job (e.g. install,
erase). See the Job class for the action and action modifier constants.
- Solvable *solvables()
+ Solvable **solvables()
my @solvables = $sel->solvables();
solvables = sel.solvables()
solvables = sel.solvables()
=== METHODS ===
- Solvable *solvables()
+ Solvable **solvables()
my @solvables = $job->solvables();
solvables = job.solvables()
solvables = job.solvables()
THE SOLVER CLASS
----------------
-xxx
+
+=== CONSTANTS ===
+
+Flags to modify some of the solver's behaviour:
+
+*SOLVER_FLAG_ALLOW_DOWNGRADE*::
+ Allow the solver to downgrade packages without asking for confirmation
+ (i.e. reporting a problem).
+
+*SOLVER_FLAG_ALLOW_ARCHCHANGE*::
+ Allow the solver to change the architecture of an installed package
+ without asking for confirmation. Note that changes to/from noarch
+ are always considered to be allowed.
+
+*SOLVER_FLAG_ALLOW_VENDORCHANGE*::
+ Allow the solver to change the vendor of an installed package
+ without asking for confirmation. Each vendor is part of one or more
+ vendor equivalence classes, normally installed packages may only
+ change their vendor if the new vendor shares at least one equivalence
+ class.
+
+*SOLVER_FLAG_ALLOW_NAMECHANGE*::
+ Allow the solver to change the name of an installed package, i.e.
+ install a package with a different name that obsoletes the installed
+ package. This option is on by default.
+
+*SOLVER_FLAG_ALLOW_UNINSTALL*::
+ Allow the solver to deinstall installed packages to fulfil the jobs.
+ This flag also includes the above flags. You may want to set this
+ flag if you only have SOLVER_ERASE jobs, as in that case it's
+ better for the user to check the transaction overview instead of
+ approving every single package that needs to be deinstalled.
+
+*SOLVER_FLAG_NO_UPDATEPROVIDE*::
+ 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. Thus, you can have an
+ official update candidate that provides the old name, and other
+ packages that also obsolete the package but are not considered for
+ updating. If you cannot use this feature, you can turn it off
+ by setting this flag.
+
+*SOLVER_FLAG_SPLITPROVIDES*::
+ Make the solver aware of special provides of the form
+ ``<packagename>:<path>'' used in SUSE systems to support package
+ splits.
+
+*SOLVER_FLAG_IGNORE_RECOMMENDED*::
+ Do not process optional (aka weak) dependencies.
+
+*SOLVER_FLAG_ADD_ALREADY_RECOMMENDED*::
+ Install recommened 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.
+
+*SOLVER_FLAG_NO_INFARCHCHECK*::
+ Turn 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.
+
+*SOLVER_FLAG_BEST_OBEY_POLICY*::
+ Make 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.
+
+*SOLVER_FLAG_NO_AUTOTARGET*::
+ Do not enable auto-targeting up update and distupgrade jobs. See
+ the section on targeted updates for more information.
+
+Basic rule types:
+
+*SOLVER_RULE_UNKNOWN*::
+ A rule of an unknown class. You should never encounter those.
+
+*SOLVER_RULE_RPM*::
+ A package dependency rule, called rpm rule for historical reasons.
+
+*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 a 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 deinstall
+ installed packages if their update rule gets disabled.
+
+*SOLVER_RULE_JOB*::
+ Job rules implement the job given to the solver.
+
+*SOLVER_RULE_DISTUPGRADE*::
+ This 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.
+
+*SOLVER_RULE_CHOICE*::
+ Choice rules are used to make sure that the solver preferes 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.
+
+*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 then other dependency solver
+ implementations.
+
+Special dependency rule types:
+
+*SOLVER_RULE_RPM_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_RPM_NOTHING_PROVIDES_DEP*::
+ The package contanis a required dependency which was not provided by
+ any package.
+
+*SOLVER_RULE_RPM_PACKAGE_REQUIRES*::
+ Similar to SOLVER_RULE_RPM_NOTHING_PROVIDES_DEP, but in this case
+ some packages provided the dependency but none of them could be
+ installed due to other dependency issues.
+
+*SOLVER_RULE_RPM_SELF_CONFLICT*::
+ The package conflicts with itself. This is not allowed by older rpm
+ versions.
+
+*SOLVER_RULE_RPM_PACKAGE_CONFLICT*::
+ To fulfill the dependencies two packages need to be installed, but
+ one of the packages contains a conflict with the other one.
+
+*SOLVER_RULE_RPM_SAME_NAME*::
+ The dependencies can only be fulfilled by multiple versions of
+ a package, but installing multiple versions of the same package
+ is not allowed.
+
+*SOLVER_RULE_RPM_PACKAGE_OBSOLETES*::
+ To fulfill the dependencies two packages need to be installed, but
+ one of the packages obsoletes the other one.
+
+*SOLVER_RULE_RPM_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_RPM_INSTALLEDPKG_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_JOB_NOTHING_PROVIDES_DEP*::
+ The user asked for installation of a package providing a specific
+ dependency, but no available package provides it.
+
+*SOLVER_RULE_JOB_UNKNOWN_PACKAGE*::
+ The user asked for installation of a package with a specific name,
+ but no available package has that name.
+
+*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), this
+ cannot be done with a job.
+
+*SOLVER_RULE_JOB_UNSUPPORTED*::
+ The user asked for something that is not yet implemented, e.g. the
+ installation of all packages at once.
+
+Policy error constants
+
+*POLICY_ILLEGAL_DOWNGRADE*::
+ The solver ask for permission before downgrading packages.
+
+*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 ask for permission before replacing an installed packages with
+ a packge that has a different name.
+
+Solution element type constants
+
+*SOLVER_SOLUTION_JOB*::
+ The problem can be solved by removing the specified job.
+
+*SOLVER_SOLUTION_POOLJOB*::
+ The problem can be solved by removing the specified job that is defined in the pool.
+
+*SOLVER_SOLUTION_INFARCH*::
+ The problem can be solved by allowing the installation of the specified package
+ with an inferior architecture.
+
+*SOLVER_SOLUTION_DISTUPGRADE*::
+ The problem can be solved by allowing to keep the specified package installed.
+
+*SOLVER_SOLUTION_BEST*::
+ The problem can be solved by allowing to install the specified package that is
+ not the best available package.
+
+*SOLVER_SOLUTION_ERASE*::
+ The problem can be solved by allowing to erase the specified package.
+
+*SOLVER_SOLUTION_REPLACE*::
+ The problem can be solved by allowing to replace the package with some other
+ package.
+
+*SOLVER_SOLUTION_REPLACE_DOWNGRADE*::
+ The problem can be solved by allowing to replace the package with some other
+ package that has a lower version.
+
+*SOLVER_SOLUTION_REPLACE_ARCHCHANGE*::
+ The problem can be solved by allowing to replace the package with some other
+ package that has a different architecture.
+
+*SOLVER_SOLUTION_REPLACE_VENDORCHANGE*::
+ The problem can be solved by allowing to replace the package with some other
+ package that has a different vendor.
+
+*SOLVER_SOLUTION_REPLACE_NAMECHANGE*::
+ The problem can be solved by allowing to replace the package with some other
+ package that has a different name.
+
+
+=== ATTRIBUTES ===
+
+ Pool *pool; /* read only */
+ $job->{'pool'}
+ d.pool
+ d.pool
+
+Back pointer to pool.
+
+=== METHODS ===
+
+ 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 solver specific flag. The flags define the policies the solver has
+to obey. The flags are explained in the CONSTANTS section of this class.
+
+ 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).
+Returns an array of problems that need user interaction, or an empty array
+if no problems were encountered. See the Problem class on how to deal with
+problems.
+
+ Transaction *transaction()
+ my $trans = $solver->transaction();
+ trans = solver.transaction()
+ trans = solver.transaction()
+
+Return the transaction to implement the calculated package changes. A transaction
+is available even if problems were found, this is useful for interactive user
+interfaces that show both the job result and the problems.
+
+THE PROBLEM CLASS
+-----------------
+
+Problems are the way of the solver to interact with the user. You can simply list
+all problems and terminate your program, but a better way is to present solutions to
+the user and let him pick the ones he likes.
+
+=== ATTRIBUTES ===
+
+ Solver *solv; /* read only */
+ $problem->{'solv'}
+ problem.solv
+ problem.solv
+
+Back pointer to solver object.
+
+ Id id; /* read only */
+ $problem->{'id'}
+ problem.id
+ problem.id
+
+Id of the problem. The first problem has Id 1, they are numbered consecutively.
+
+=== METHODS ===
+
+ Rule *findproblemrule()
+ my $probrule = $problem->findproblemrule();
+ probrule = problem.findproblemrule()
+ probrule = problem.findproblemrule()
+
+Return the rule that caused the problem. Of cource in most situations there is no
+single responsible rule, but many rules that interconnect with each created the
+problem. Nevertheless, the solver uses some heuristic approch to find a rule
+that somewhat describes the problem best to the user.
+
+ Rule **findallproblemrules(bool unfiltered = 0)
+ my @probrules = $problem->findallproblemrules();
+ probrules = problem.findallproblemrule()
+ probrules = problem.findallproblemrule()
+
+Return all rules responsible for the problem. The returned set of rules contains
+all the needed information why there was a problem, but it's hard to present
+them to the user in a sensible way. The default is to filter out all update and
+job rules (unless the returned rules only consist of those types).
+
+ Solutions **solutions()
+ my @solutions = $problem->solutions();
+ solutions = problem.solutions()
+ solutions = problem.solutions()
+
+Return an array containing multiple possible solutions to fix the problem. See
+the solution class for more information.
+
+ int solution_count()
+ my $cnt = $problem->solution_count();
+ cnt = problem.solution_count()
+ cnt = problem.solution_count()
+
+Return the number of solutions without creating solution objects.
+
+THE RULE CLASS
+--------------
+
+Rules are the basic block of sat solving. Each package dependency gets translated
+into one or multiple rules.
+
+=== ATTRIBUTES ===
+
+ Solver *solv; /* read only */
+ $rule->{'solv'}
+ rule.solv
+ rule.solv
+
+Back pointer to solver object.
+
+ Id id; /* read only */
+ $rule->{'id'}
+ rule.id
+ rule.id
+
+The id of the rule.
+
+ int type; /* read only */
+ $rule->{'type'}
+ rule.type
+ rule.type
+
+The basic type of the rule. See the constant section of the solver class for the type list.
+
+=== METHODS ===
+
+ Ruleinfo *info()
+ my $ruleinfo = $rule->info();
+ ruleinfo = rule.info()
+ ruleinfo = rule.info()
+
+Return a Ruleinfo object that contains information about why the rule was created. But
+see the allinfos() method below.
+
+ Ruleinfo **allinfos()
+ my @ruleinfos = $rule->allinfos();
+ ruleinfos = rule.allinfos()
+ ruleinfos = rule.allinfos()
+
+As the same dependency rule can get created because of multiple dependencies, one
+Ruleinfo is not enough to describe the reason. Thus the allinfos() method returns
+an array of all infos about a rule.
+
+ <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.
+
+THE RULEINFO CLASS
+------------------
+
+A Ruleinfo describes one reason why a rule was created.
+
+=== ATTRIBUTES ===
+
+ Solver *solv; /* read only */
+ $ruleinfo->{'solv'}
+ ruleinfo.solv
+ ruleinfo.solv
+
+Back pointer to solver object.
+
+ int type; /* read only */
+ $ruleinfo->{'type'}
+ ruleinfo.type
+ ruleinfo.type
+
+The type of the ruleinfo. See the constant section of the solver class for the
+rule type list and the special type list.
+
+ Dep *dep; /* read only */
+ $ruleinfo->{'dep'}
+ ruleinfo.dep
+ ruleinfo.dep
+
+The dependency leading to the creation of the rule.
+
+ 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.
+
+ Solvable *solvable; /* read only */
+ $ruleinfo->{'solvable'}
+ ruleinfo.solvable
+ ruleinfo.solvable
+
+The involved Solvable, e.g. the one containing the dependency.
+
+ Solvable *othersolvable; /* read only */
+ $ruleinfo->{'othersolvable'}
+ ruleinfo.othersolvable
+ ruleinfo.othersolvable
+
+The other involved Solvable (if any), e.g. the one containing providing
+the dependency for conflicts.
+
+ const char *problemstr();
+ my $str = $ruleinfo->problemstr();
+ str = ruleinfo.problemstr()
+ str = ruleinfo.problemstr()
+
+A string describing the ruleinfo from a problem perspective. This probably
+only makes sense if the rule is part of a problem.
+
+THE SOLUTION CLASS
+------------------
+
+A solution solves one specific problem. It consists of multiple solution elements
+that all need to be executed.
+
+=== ATTRIBUTES ===
+
+ Solver *solv; /* read only */
+ $solution->{'solv'}
+ solution.solv
+ solution.solv
+
+Back pointer to solver object.
+
+ Id problemid; /* read only */
+ $solution->{'problemid'}
+ solution.problemid
+ solution.problemid
+
+Id of the problem the solution solves.
+
+ Id id; /* read only */
+ $solution->{'id'}
+ solution.id
+ solution.id
+
+Id of the solution. The first solution has Id 1, they are numbered consecutively.
+
+=== METHODS ===
+
+ Solutionelement **elements(bool expandreplaces = 0)
+ my @solutionelements = $solution->elements();
+ solutionelements = solution.elements()
+ solutionelements = solution.elements()
+
+Return an array containing the elements describing what neeeds to be done to
+implement the specific solution. If expandreplaces is true, elements of type
+SOLVER_SOLUTION_REPLACE will be replaced by one or more elements replace
+elements describing the policy mismatches.
+
+ int element_count()
+ my $cnt = $solution->solution_count();
+ cnt = solution.element_count()
+ cnt = solution.element_count()
+
+Return the number of solution elements without creating objects. Note that the
+count does not match the number of objects returned by the elements() method
+of expandreplaces is set to true.
+
+
+THE SOLUTIONELEMENT CLASS
+-------------------------
+
+A solution element describes a single action of a solution. The action is always
+either to remove one specific job or to add a new job that installs or erases
+a single specific package.
+
+=== ATTRIBUTES ===
+
+ Solver *solv; /* read only */
+ $solutionelement->{'solv'}
+ solutionelement.solv
+ solutionelement.solv
+
+Back pointer to solver object.
+
+ Id problemid; /* read only */
+ $solutionelement->{'problemid'}
+ solutionelement.problemid
+ solutionelement.problemid
+
+Id of the problem the element (partly) solves.
+
+ Id solutionid; /* read only */
+ $solutionelement->{'solutionid'}
+ solutionelement.solutionid
+ solutionelement.solutionid
+
+Id of the solution the element is a part of.
+
+ Id id; /* read only */
+ $solutionelement->{'id'}
+ solutionelement.id
+ solutionelement.id
+
+Id of the solution element. The first element has Id 1, they are numbered consecutively.
+
+ Id type; /* read only */
+ $solutionelement->{'type'}
+ solutionelement.type
+ solutionelement.type
+
+Type of the solution element. See the constant section of the solver class for the
+existing types.
+
+ Solvable *solvable; /* read only */
+ $solutionelement->{'solvable'}
+ solutionelement.solvable
+ solutionelement.solvable
+
+The installed solvable that needs to be replaced for replacement elements.
+
+ Solvable *replacement; /* read only */
+ $solutionelement->{'replacement'}
+ solutionelement.replacement
+ solutionelement.replacement
+
+The solvable that needs to be installed to fix the problem.
+
+ 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 of another type. Note that it's better to change the job to SOLVER_NOOP
+type so that the numbering of other elements does not get disturbed. This
+method works both for types SOLVER_SOLUTION_JOB and SOLVER_SOLUTION_POOLJOB.
+
+=== METHODS ===
+
+ Solutionelement **replaceelements()
+ my @solutionelements = $solutionelement->replaceelements();
+ solutionelements = solutionelement.replaceelements()
+ solutionelements = solutionelement.replaceelements()
+
+If the solution element is of type SOLVER_SOLUTION_REPLACE, return an array of
+elements describing the policy mismatches, otherwise return a copy of the
+element. See also the ``expandreplaces'' option in the solution's elements()
+method.
+
+ int illegalreplace()
+ my $illegal = $solutionelement->illegalreplace();
+ illegal = solutionelement.illegalreplace()
+ illegal = solutionelement.illegalreplace()
+
+Return an integer that contains the policy mismatch bits or-ed together, or
+zero if there was no policy mismatch. See the policy error constants in
+the solver class.
+
+ Job *Job()
+ my $job = $solutionelement->Job();
+ illegal = solutionelement.Job()
+ illegal = solutionelement.Job()
+
+Create a job that implements the solution element. Add this job to the array
+of jobs for all elements of type different to SOLVER_SOLUTION_JOB and
+SOLVER_SOLUTION_POOLJOB. For the later two, a SOLVER_NOOB Job is created,
+you should replace the old job with the new one.
+
+ const char *str()
+ my $str = $solutionelement->str();
+ str = solutionelement.str()
+ str = solutionelement.str()
+
+A string describing the change the solution element consists of.
THE TRANSACTION CLASS
---------------------
-xxx
+
+=== CONSTANTS ===
+
+Transaction element types, both active and passive
+
+*SOLVER_TRANSACTION_IGNORE*::
+ This element does nothing. Used to map element types that do not
+ match the view mode.
+
+*SOLVER_TRANSACTION_INSTALL*::
+ This element installes a package.
+
+*SOLVER_TRANSACTION_ERASE*::
+ This element erases a package.
+
+*SOLVER_TRANSACTION_MULTIINSTALL*::
+ This element installs a package with a different version keeping the
+ other versions installed.
+
+*SOLVER_TRANSACTION_MULTIREINSTALL*::
+ This element reinstalls a 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 same name, version, architecture but
+ different content.
+
+*SOLVER_TRANSACTION_UPGRADE*::
+ This element installs a newer version of an installed package.
+
+*SOLVER_TRANSACTION_DOWNGRADE*::
+ This element installs a older version of an installed package.
+
+*SOLVER_TRANSACTION_OBSOLETES*::
+ This element installs a package that obsoletes an installed package.
+
+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, 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 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 OBSOLETE element, the other ones are mapped to INSTALL/ERASE
+ elements. This is because most applications want to show just one package
+ replacing the installed one. The SOLVER_TRANSACTION_SHOW_ALL 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 the 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, 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.
+ This flag is needed if you want to do manual ordering.
+
+=== ATTRIBUTES ===
+
+ Pool *pool; /* read only */
+ $trans->{'pool'}
+ trans.pool
+ trans.pool
+
+Back pointer to pool.
+
+=== METHODS ===
+
+ bool isempty();
+ $trans->isempty()
+ trans.isempty()
+ trans.isempty?
+
+Returns true if the transaction does not do anything, i.e. has no elements.
+
+ Solvable **newpackages();
+ my @newsolvables = $trans->newpackages();
+ newsolvables = trans.newpackages()
+ newsolvables = trans.newpackages()
+
+Return all packages that are to be installed by the transaction. This are
+the packages that need to be downloaded from the repositories.
+
+ Solvable **keptpackages();
+ my @keptsolvables = $trans->keptpackages();
+ keptsolvables = trans.keptpackages()
+ keptsolvables = trans.keptpackages()
+
+Return all installed packages that the transaction will keep installed.
+
+ 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 that 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 the best package of the obsoleting packages if
+the package does not get replaced by one with the same name.
+
+For to be installed packages, the ``other'' solvable is the best installed
+package with the same name that will be replaced, or the best packages
+of all the packages that are obsoleted if the new package does not replace
+a package with the same name.
+
+Thus, the ``other'' solvable is normally the package that is also shown
+for a given package.
+
+ 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.
+
+ int 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).
+
+ void order(int flags = 0);
+ $trans->order();
+ trans.order()
+ trans.order()
+
+Order the steps in the transactions so that dependant packages are updated
+before packages that depend on them. For rpm, you can also use rpmlib's
+ordering functionality, debian's dpkg does not provide a way to order a
+transaction.
+
+=== ACTIVE/PASSIVE VIEW ===
+
+Active view list what new packages get installed, while passive view shows
+what happens to the installed packages. Most often there's not much
+difference between the two modes, but things get interesting of multiple
+package get replaced by one new package. Say you have installed package
+A-1-1 and B-1-1, and now install A-2-1 with 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 containes 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.
+
+=== ATTRIBUTES ===
+
+ Transaction *transaction; /* read only */
+ $class->{'transaction'}
+ class.transaction
+ class.transaction
+
+Back pointer to 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
---------
projects / platform / upstream / libsolv.git / blobdiff