Re: [zypp-devel] excluding one package in a pattern in libzypp
On Thursday 18 July 2013 10:23:34 Chen, Gui wrote:
> I tried the two ways here:
> 1. steps:
> 'select pattern base'
> 'deselect package A'
> 'resolve pool'
> Result: A, B, C, D
...
> I attached my source code, which was adapted to use the first way.
> And I have tested in openSUSE 12.2, it runs successfully, my chroot
> includes A, B, C, D however, instead of printing resolve problems.
I modified your code to print out the return values of the status changes you
apply in mark_poolitem. (restore the location of your repo)
=== U_Tu_(6)pattern:base-.noarch(tmp) applied setToBeInstalled
This is currently selected:
U_Tu_(6)pattern:base-.noarch(tmp)
=== U__s_(5)A-0.1-1.x86_64(tmp) applied resetTransact
=== U__s_(5)A-0.1-1.x86_64(tmp) FAILED TO APPLY setToBeUninstalled
This is currently selected:
U_Tu_(6)pattern:base-.noarch(tmp)
This would have been commited:
U_Ts_(2)D-1.0-1.x86_64(tmp)
U_Ts_(3)C-0.1-1.x86_64(tmp)
U_Ts_(4)B-1.0-1.x86_64(tmp)
U_Ts_(5)A-0.1-1.x86_64(tmp)
USTu_(6)pattern:base-.noarch(tmp)
Actually you did not deselect A. Only pattern:base is selected and resolved.
That's why A,B,C,D are installed.
Why?
A PoolItem combines the basic data of a single package(pattern/patch/..)
instance with a simple status. Package instances are found in the rpm
database (@System) as well as in repositories.
On a typical system you will have multiple instances of a package called
e.g. "kernel":
installed:kernel-1.0 (@System)
kernel-1.1 (@System)
available:kernel-1.0 (repo: foo)
kernel-1.1 (repo: foo-updates)
kernel-1.2 (repo: foo-updates)
kernel-2.0 (repo: experimental)
So you have 6 PoolItems named "kernel". The status of each PoolItem describes
this instances fate:
- unchanged: nothing happens
- transacts: for an installed item it means it gets deleted;
for an available item it means it gets installed;
- locked: not allowed to change the status; raises a resolver
conflict if a change would be necessary.
In your case you requested setToBeUninstalled for an available PoolItem. As
the item is not installed, the request can't be fulfilled.
What you wanted is to lock A, in fact all available instances of A if there
were multiple, so the solver will not be allowed to select any of them and
raise a conflict instead.
Obviously by looking at a single PoolItem you do not get the whole picture.
You always need to consider all PoolItems for of given name in order to see
what is, and what will happen. A 'normal' package update for example will
cause the installed as well as one available PoolItem to 'transact'. Only in
case multiple versions of a package can be installed in parallel (e.g.
kernel), each PoolItem can be treated (more or less) independently.
The above collection of all PoolItems of the same name is available as
ui::Selectable. This class also allows to get/set an overall status for
this 'name' (translating this into solver requests and adjusting the
individual PoolItems):
ui::Selectable::Ptr sel = ui::Selectable::get( "A" ); // (package) A
if ( ! sel )
std::cout << "No package:A in the pool" << endl;
else if ( ! sel->setStatus( ui::S_Taboo, ResStatus::USER ) )
std::cout << "FAILED to set S_Taboo on " << sel << endl;
// ui::Selectable::get( ResKind::package, "A" );
// ui::Selectable::get( ResKind::pattern, "base" );
// ui::Selectable::get( IdString( "pattern:base" ) );
// also get from Solvable or PoolItem
With the above fix, you get the desired resolver conflict. Choosing to ignore
it. you get D,C installed:
Problem:
==
pattern:base-.noarch requires A, but this requirement cannot be provided
uninstallable providers: A-0.1-1.x86_64[tmp]
--
Solution:
do not forbid installation of A-0.1-1.x86_64[tmp]
TransactionSolutionAction: Unlock U_Lu_(5)A-0.1-1.x86_64(tmp)
Solution:
do not install pattern:base-.noarch
TransactionSolutionAction: Keep UBTu_(6)pattern:base-.noarch(tmp)
Solution:
break pattern:base-.noarch by ignoring some of its dependencies
InjectSolutionAction: Weak UBTu_(6)pattern:base-.noarch(tmp)
==
PICK LAST SOLUTION
SOLVE AGAIN
This would have been commited:
U_Ts_(2)D-1.0-1.x86_64(tmp)
U_Ts_(3)C-0.1-1.x86_64(tmp)
UBTu_(6)pattern:base-.noarch(tmp)
JFYI: There is also a way to directly file solver requests. It is currently a
bit limited, as it just supports Capabilities (you 'd not be be asking
for 'package A' but for 'something providing A', which is close, but not
exactly the same). This API will be enhanced as it's probably nice to usee
for simple tasks.
ResPool pool( ResPool::instance() );
pool.resolver().addRequire( Capability("pattern:base") );
RE: [zypp-devel] excluding one package in a pattern in libzypp
I tried the two ways here: 1. steps: 'select pattern base' 'deselect package A' 'resolve pool' Result: A, B, C, D 2. steps: 'select pattern base' 'resolve pool' 'deselect package A' Result: B, C, D I attached my source code, which was adapted to use the first way. And I have tested in openSUSE 12.2, it runs successfully, my chroot includes A, B, C, D however, instead of printing resolve problems. Thanks Gui -Original Message- From: Michael Andres [mailto:m...@suse.de] Sent: Wednesday, July 17, 2013 11:31 PM To: zypp-devel@opensuse.org Cc: Chen, Gui; Zhang, Qiang Z Subject: Re: [zypp-devel] excluding one package in a pattern in libzypp On Wednesday 17 July 2013 09:15:13 Chen, Gui wrote: > Hi list, > > I am trying to create a chroot with libzypp, and I found when I need > to remove a package and this package is part of a pattern which will > be installed, the dependencies of the package will stay there. For > example, if 'A' and 'C' are in a pattern 'base', and 'A' requires 'B', > 'C' requires 'D', I need to install pattern 'base', also I need to set > 'A' uninstalled, but I end up having 'B', 'C', 'D' in my chroot. If I > am not installing 'A', I definitely needn't 'B' installed. > Is there any comment? should I file a bug? How did you do it? You can't 'install pattern:base' and 'remove A' in one step, because 'pattern:base requires A': 'select pattern:base' 'deselect A' 'resolve pool' (fails: pattern:base requires A') What you describe could be created this way: 'select pattern:base' 'resolve pool' (will select A C, B, D) 'deselect A' Here 'D' is still selected, but just because 'resolve pool' was not called after changing the selection. However, if a 'resolve pool' fails, the Resolver provides list of 'Resolver::problems()'. Each Problem usually has a list of solutions(). A ProblemSolution can be applied to the resolver. Problem 1: pattern:base requires A, but this requirement cannot be provided Solutions for problem #1: do not ask to delete all solvables providing A do not ask to install a solvable providing pattern:base ==> ignore some dependencies of pattern:base If I apply the last solution, then resolve again, I get C and D selected. -- cu, Michael Andres +--+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +--+ Michael Andres SUSE LINUX Products GmbH, Development, m...@suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +--+ group.cc Description: group.cc repository.tar.gz Description: repository.tar.gz
Re: [zypp-devel] excluding one package in a pattern in libzypp
On Wednesday 17 July 2013 09:15:13 Chen, Gui wrote: > Hi list, > > I am trying to create a chroot with libzypp, and I found when I need to > remove a package and this package is part of a pattern which will be > installed, the dependencies of the package will stay there. For example, if > 'A' and 'C' are in a pattern 'base', and 'A' requires 'B', 'C' requires > 'D', I need to install pattern 'base', also I need to set 'A' uninstalled, > but I end up having 'B', 'C', 'D' in my chroot. If I am not installing 'A', > I definitely needn't 'B' installed. > Is there any comment? should I file a bug? How did you do it? You can't 'install pattern:base' and 'remove A' in one step, because 'pattern:base requires A': 'select pattern:base' 'deselect A' 'resolve pool' (fails: pattern:base requires A') What you describe could be created this way: 'select pattern:base' 'resolve pool' (will select A C, B, D) 'deselect A' Here 'D' is still selected, but just because 'resolve pool' was not called after changing the selection. However, if a 'resolve pool' fails, the Resolver provides list of 'Resolver::problems()'. Each Problem usually has a list of solutions(). A ProblemSolution can be applied to the resolver. Problem 1: pattern:base requires A, but this requirement cannot be provided Solutions for problem #1: do not ask to delete all solvables providing A do not ask to install a solvable providing pattern:base ==> ignore some dependencies of pattern:base If I apply the last solution, then resolve again, I get C and D selected. -- cu, Michael Andres +--+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +--+ Michael Andres SUSE LINUX Products GmbH, Development, m...@suse.de GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer, HRB16746(AG Nürnberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +--+ -- To unsubscribe, e-mail: zypp-devel+unsubscr...@opensuse.org To contact the owner, e-mail: zypp-devel+ow...@opensuse.org
