May 2008 - Zypp Development - openSUSE Mailing Lists

[zypp-devel] Delta RPMs are back
by Jan Kupec 19 May '08

19 May '08

Hi, the delta rpms now work again, we can start generate (test) repos containing them. There are some differences compared to old implementation: - new metadata format (yum-presto, deltainfo.xml) (where to document this?) - delta and package buildtime attributes are dropped, as well as the target package checksum (we never used them) - Delta from _any_ repository can now be applied (repository of origin is now stored in delta created using Repository and sat-extra Id). If we don't want this, or if we want to make it subject to some policy, let me know. - only deltas matching target package names are now fetched into DeltaCandidates list, so some memory/speed will be saved. - the current code is ugly (PackageDelta.cc), so i will beautify it a bit. I would definitely like to reuse LookupAttr code (the as{FooType}() methods at least). I'm just not sure whether to do it now, or post 11.0. cheers, jano ------------------------------------------------------------------------ $ zypper in kile Reading installed packages... The following package is going to be upgraded: kile Overall download size: 4.6 M. No additional space will be used or freed after the operation. Continue? [YES/no]: Downloading package kile-2.0.1rc1-13.x86_64, 4.6 M (11.2 M unpacked) Downloading delta: ./DRPMS/kile-2.0.1rc1-10_2.0.1rc1-13.x86_64.drpm, 170.8 K Downloading: kile-2.0.1rc1-10_2.0.1rc1-13.x86_64.drpm [done] Applying delta: ./kile-2.0.1rc1-10_2.0.1rc1-13.x86_64.drpm [done] Installing: kile-2.0.1rc1-13 [done] $ rpm -q kile kile-2.0.1rc1-13 -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

Re: [zypp-devel] zypper performance gone bad, bad, bad
by josef reidiner 19 May '08

19 May '08

Stephan Kulow napsal(a): > Am Freitag, 16. Mai 2008 schrieben Sie: >> Stephan Kulow napsal(a): >>> Hi, >>> >>> Looks like the implementation of locks has all the old >>> problems ;( >>> >>> I cancelled the callgrind call, but till then it called >>> 415 826 times PoolQueryIterator::matchSolvable, which in >>> turn costed 28 382 428 146 instructions. >>> >>> Greetings, Stephan >> Locks depends on PoolQuery which uses DataIterator...if we expect lot of >> locks from ui, which is exact string match, then we can optimalize >> PoolQuery (or directly locks by extracting information about lock from >> query) for this (e.g. using index on names). >> > > I think one problem is that "zypper addlock kernel-debug" adds > match_type: glob (no idea why) > > And then you do a glob search even if there are no * or ? - which > could be optimized too. > > Greetings, Stephan I agree, this is ineffective and check for * or ? is quite fast during adding. I add it if jano isn't faster :) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] RFC: config Parameter ShowSearchDetails
by Dominique Leuenberger 17 May '08

17 May '08

Hi, Recently, the search within zypper was changed to no longer show version information and repositories holding a package. Either I just got to used to it or I'm really missing it. I know of the --details switch, which became a standard for me by now and I was wondering if there were any plans for a config switch (/etc/zypp/zypp.conf) like ShowSearchDetails: {true,false} This should change the default behavior of zypper search and add --details in case it's requested. I assume, in this case, we'd also need a --no-details parameter for search, just in case a user that has it on by default wishes to override it for one search. I understand you all are very busy and in case this is a feature you'd think would make sense, I would offer myself to jump into it and provide a patch (I assume this should not be to difficult to implement... tell me if I should be wrong here; my coding knowledge is not that recent anymore). Best regards, Dominique -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

5 7

[zypp-devel] zypper performance gone bad, bad, bad
by Stephan Kulow 16 May '08

16 May '08

Hi, Looks like the implementation of locks has all the old problems ;( I cancelled the callgrind call, but till then it called 415 826 times PoolQueryIterator::matchSolvable, which in turn costed 28 382 428 146 instructions. Greetings, Stephan linux-wcg3:/home/coolo # time zypper in fate Reading installed packages... 'fate' is already installed. Nothing to do. real 0m1.648s user 0m1.240s sys 0m0.360s linux-wcg3:/home/coolo # mv /etc/zypp/locks{.away,} linux-wcg3:/home/coolo # grep kind /etc/zypp/locks | wc -l 8 linux-wcg3:/home/coolo # time zypper in fate Reading installed packages... 'fate' is already installed. Nothing to do. real 0m21.176s user 0m20.449s sys 0m0.592s -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] Re: [zypp-commit] r10132 - in /trunk/libzypp-testsuite: libzypp-testsuite-tools.spec.in solver/src/Makefile.am solver/src/deptestomatic.cc
by Michael Matz 16 May '08

16 May '08

Hi schubi, On Fri, 16 May 2008, matz(a)svn.opensuse.org wrote: > Author: matz > Date: Fri May 16 18:06:11 2008 > New Revision: 10132 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=10132&view=rev > Log: > We don't have a libqdialog1-devel package in STABLE anymore. Needs to > be submitted before activating this code again. > > Modified: > trunk/libzypp-testsuite/libzypp-testsuite-tools.spec.in > trunk/libzypp-testsuite/solver/src/Makefile.am > trunk/libzypp-testsuite/solver/src/deptestomatic.cc I initially tried fixing CruiseControl by simply rebuilding the chroot that now required libqdialogsolver1-devel. That broke, and much to my amazement we don't _have_ any such package in STABLE at all. It seemed to only ever have existed in the 10.3 branch. So, please submit such package to stable, and revert my revert only after it got checked in and was built at least once :) Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

1 0

[zypp-devel] zypper: Root privileges are required for modifying system repositories...
by Michael Andres 15 May '08

15 May '08

ma@Fibonacci:~ $ rm -rf /tmp/rr ma@Fibonacci:~ $ zypper --root /tmp/rr sa http://download.opensuse.org/distribution/SL-OSS-factory/inst-source Root privileges are required for modifying system repositories. Why should the above require Root privileges? Shouldn't we actually check whether we are aloowed to read/write the directories? -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma(a)novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

4 3

[zypp-devel] Re: [zypp-commit] r10079 - /trunk/sat-solver/doc/SOLVER
by Stefan Schubert 15 May '08

15 May '08

I know someone who has told us to document all libzypp stuff in Wiki ;-) http://en.opensuse.org/Package_Management/Sat_Solver/Internals Greetings Stefan kkaempf(a)svn.opensuse.org schrieb: > Author: kkaempf > Date: Tue May 13 18:10:56 2008 > New Revision: 10079 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=10079&view=rev > Log: > In the beginning, there was nothing. > On the first weekend, an initial documentation was created. > > Added: > trunk/sat-solver/doc/SOLVER > > Added: trunk/sat-solver/doc/SOLVER > URL: http://svn.opensuse.org/viewcvs/zypp/trunk/sat-solver/doc/SOLVER?rev=10079&… > ============================================================================== > --- trunk/sat-solver/doc/SOLVER (added) > +++ trunk/sat-solver/doc/SOLVER Tue May 13 18:10:56 2008 > @@ -0,0 +1,209 @@ > +How the sat-solver works > +------------------------ > + > +I. Data structure > +----------------- > + Id p; /* first literal in rule */ > + Id d; /* Id offset into 'list of providers */ > + /* terminated by 0' as used by whatprovides; pool->whatprovides + d */ > + /* in case of binary rules, d == 0, w1 == p, w2 == other literal */ > + /* in case of disabled rules: ~d, aka -d - 1 */ > + Id w1, w2; /* watches, literals not-yet-decided */ > + /* if !w2, assertion, not rule */ > + Id n1, n2; /* next rules in linked list, corresponding to w1,w2 */ > + > + > + r->n1 = solv->watches[nsolvables + r->w1]; > + solv->watches[nsolvables + r->w1] = r - solv->rules; > + > + r->n2 = solv->watches[nsolvables + r->w2]; > + solv->watches[nsolvables + r->w2] = r - solv->rules; > + > + > + * Assertion > + * keepinstalled (A), install > + p=A, d=0, w1=p, w2=0 > + * uninstallable (-A), remove > + p=-A, d=0, w1=p, w2=0 > + * > + * Binary rules: > + * (A|B) > + p=A, d=0, w1=p, w2=B > + * (-A|B) > + p=-A, d=0, w1=p, w2=B > + * > + * A requires B : !A | provider1(B) | provider2(B) > + p=-A, d=<whatprovides_offset>, w1=, w2= > + > + * B updates A : A | provider1(B) | provider2(B) > + p=A, d=<whatprovides_offset>, w1=, w2= > + > + * > + * A conflicts B : (!A | !provider1(B)) & (!A | !provider2(B)) ... > + p=-A, d=-B1, w1=, w2= > + p=-A, d=-B2, w1=, w2= > + p=-A, d=-B3, w1=, w2= > + ... > + * > + * 'not' is encoded as a negative Id > + * > + > +Action | p | d | w1 | w2 > +--------------+----+---------+-------+-------- > +Assert A | A | 0 | A | 0 > +Assert -A |-A | 0 |-A | 0 > +Binary A,B | A | 0 | A | B > +Binary -A,B |-A | 0 |-A | B > +A requires B |-A | prov(B) |-A | whatprovidesdata(B) > +B updates A | A | prov(B) | A | whatprovidesdata(B) > +A conflicts B |-A | -B |-A |-B > + > + > +addrule(p, d) > + > + > +/* > +* add rule > +* p = direct literal; always < 0 for installed rpm rules > +* d, if < 0 direct literal, if > 0 offset into whatprovides, if == 0 rule is assertion (look at p only) > +* > +* > +* A requires b, b provided by B1,B2,B3 => (-A|B1|B2|B3) > +* > +* p < 0 : pkg id of A > +* d > 0 : Offset in whatprovidesdata (list of providers of b) > +* > +* A conflicts b, b provided by B1,B2,B3 => (-A|-B1), (-A|-B2), (-A|-B3) > +* p < 0 : pkg id of A > +* d < 0 : Id of solvable (e.g. B1) > +* > +* d == 0: unary rule, assertion => (A) or (-A) > +* > +* Install: p > 0, d = 0 (A) user requested install > +* Remove: p < 0, d = 0 (-A) user requested remove > +* Requires: p < 0, d > 0 (-A|B1|B2|...) d: <list of providers for requirement of p> > +* Updates: p > 0, d > 0 (A|B1|B2|...) d: <list of updates for solvable p> > +* Conflicts: p < 0, d < 0 (-A|-B1),(-A|-B2),... either p (conflict issuer) or d (conflict provider) (binary rule) > +* Obsoletes: p < 0, d < 0 (-A|-B1),(-A|-B2),... A: uninstalled, Bx = provider of obsoletes > +* ? p > 0, d < 0 (A|-B) > +* No-op: p = 0, d = 0 (null) (used as policy rule placeholder) > +* install one of: p =-SYS, d > 0 > +* > +* resulting watches: > +* ------------------ > +* Direct assertion (no watch needed)( if d <0 ) --> d = 0, w1 = p, w2 = 0 > +* Binary rule: p = first literal, d = 0, w2 = second literal, w1 = p > +* every other : w1 = p, w2 = whatprovidesdata[d]; > +* Disabled rule: d < 0, w1 = 0 > +* > +* always returns a rule for non-rpm rules > +*/ > + > +enablerule: > + if (d < 0): d = -d - 1 > +disablerule > + if (d >= 0): d = -d - 1 > + > + > +Watches > +------- > + > +Watches 'link' rules involving the same literal > +Only for n-ary (n >= 2) rules, not for assertions > + > + > +Watches start at solv->watches[nsolvables] > + > +watches[nsolvables+s] == rule installing s > +watches[nsolvables-s] == rule removing s > + > +'watches trigger when literal goes false' > + > +watches[A] = rule involving A > + rule->n1 = next rule involving A > +watches[B] = rule involving B > + rule->n2 = next rule involving B > + > + > +Propagation > +----------- > + > +This distributes decisions among affected rules and checks that rules > +evaluate to 'true'. > + > +Since rules are in CNF (conjunctive normal form), it is sufficient for > +one sub-term (x or y in x|y) to become 'true'. > + > +The interesting case is a 'false' sub-term (x or y in x|y) because > +this requires the 'other' side to become true. > + > + > + > +II. Algorithm > +------------- > + > +- set up rules for installed packages > +if (installed) > + foreach(installed): addrpmrulesforsolvable > + convert dependencies of solvable into rules > + run through the complete graph of dependencies spawned the solvable > + foreach(installed): addrpmrulesforupdaters > + add rules to allow updates: A | upates(A) > + > +- set up rules for solvables mentioned in job > + foreach (install request) > + addrpmrulesforsolvable > + foreach (update request) > + addrpmrulesforupdaters > + /* dont look at removals */ > + > +- addrpmrulesforweak > + if suggests: add dependency rule > + else if freshens: add dependency rule > + else if enhances: add dependency rule > + > +- add feature rules > + > +- add update rules > + > +- add job rules > + > +During solving, we only look at those rules affected by the job or a > +decision. By use of the linked-list rooted at 'watches', the solver is > +able to wade through all the rules and pick the right ones. > + > +And only those have to evaluate to 'true' during propagation. > + > +Actual solving works as follows > +------------------------------- > + > +- ensure the SYSTEM solvable gets installed > +- look through the job rules for 'unit' rules > + (i.e. rules directly installing/removing a solvable) > + > +- These two define the 'initial decisions' which now get propagated > +- propagation either results in other decisions (i.e. one sub-term > + false requires the other one to become true) or 'free' literals > + (which are decided by policy heuristics) > + > +- The solver has a 'decisionq' which record decisions (> 0 for > + 'install', < 0 for 'remove') > + Every decision has an 'index' (== position in decisionq) > + There are two 'pointers' > + - decisionq.count == total number of made decision > + - propagate_index == number of already propagated decisions > + > + Decisions are also recorded in decisionmap, indexed by the solvable > + Id. This is a fast access to decisions (instead of searching in the > + queue) > + > + And there is 'decisionq_why', indexed by the decision number (level) > + returning the rule leading to the decision. > + > + propagate() now tries to advance propagate_index to decisionq.count > + in order to propagate all decisions to all (affected) rules. > + propagate() also ensures that decisions are consistent (else its a > + solver conflict) and all affected rules evaluate to 'true'. > + > + When rules are reduced to 'unit' (only one undecided literal, all > + others 'false'), the last literal must be decided to 'true'. > > -- ******************************************************************************* Stefan Schubert SUSE LINUX GmbH - Maxfeldstrasse 5 - D-90409 Nuernberg, Germany e-mail: schubi(a)suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] Re: [zypp-commit] r10066 - in /trunk/sat-solver: package/libsatsolver.changes src/solvable.c
by Michael Schroeder 13 May '08

13 May '08

On Tue, May 13, 2008 at 10:24:57AM -0000, dmacvicar(a)svn.opensuse.org wrote: > Author: dmacvicar > Date: Tue May 13 12:24:57 2008 > New Revision: 10066 > > URL: http://svn.opensuse.org/viewcvs/zypp?rev=10066&view=rev > Log: > a boolean is not a num attribute set to 1, but just a existing void > attribute. (bnc#388818) Then could we please get rid of the solvable_lookup_bool function? Michael. -- Michael Schroeder mls(a)suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

2 1

[zypp-devel] script to convert old locks to new
by Josef Reidinger 09 May '08

09 May '08

I attach script which converts old locks to new format. Problem is, that new locks (as PoolQuery) doesn't support version restrict. So convertor ignore version restrict. Due to this, converted locks is created in /tmp directory and you can check it before move it over old file. comments welcome Pepa

1 1

[zypp-devel] 'zypper up -t package' no longer working?
by Dominique Leuenberger 07 May '08

07 May '08

Hi everybody, It seems zypper up -t package is no longer working... or did the syntax change? I can issue zypper lu -t package and it shows me a list (n elements) issuing zypper up -t package afterwards tells me 'nothing to do'. Even weirder: # zypper sh zypper>lu -t package here a dummy list of packages to be updated. n elements, n>1 zypper>up -t package Nothing to do zypper>in <any element from list> Nothing to do zypper>quit # zypper sh zypper>in <any element from list> <element from list> is being installed <any element from list> was the same in every try. so up -t package seems to break the whole shell a bit at the moment. Any internal hacker already seen this behaviour? (or am I simply the only one to use shell all the time?) Dominique -- To unsubscribe, e-mail: zypp-devel+unsubscribe(a)opensuse.org For additional commands, e-mail: zypp-devel+help(a)opensuse.org

3 2