Re: [gentoo-portage-dev] DepSet

[Jason Stubbs]

On Friday 09 December 2005 04:03, Zac Medico wrote:
 Jason Stubbs wrote:
  On Thursday 08 December 2005 16:44, Zac Medico wrote:
 The middle hunk fixes a problem with block atoms that do not match any
 packages.  Previously, these atoms would not make it into the okay_atoms
  set which caused unresolved dependencies.
 
  Are you sure about this?

 Well, I'm pretty sure. You're analysis seems to be perfectly correct except
 for 2 points that you haven't accounted for:

 1) The atom.key != child.key optimization prevents the atom.match(child) ^
 atom.blocks bit from working in the case that my patch handles (block atom
 that does not match any package).

 2) Without the atom.key != child.key optimization, the original algorithm
 would bail out early, before all packages have been checked.  We need to
 ensure that the atom does not block _any_ of the packages before we add it
 to okay_atoms, otherwise, we risk choosing the wrong atomset/combination. 
 Note that checking all the packages _does_ introduce a performance penalty
 for block atoms.

Damn optimizations. :|

Both points are correct.

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] DepSet

[Zac Medico]

Zac Medico wrote:


1) Save test_conditionals.py in your PYTHONPATH as 
portage/test/ebuild/test_conditionals.py


2) Run `trial portage.test.ebuild` and watch it fail.

3) Apply DepSet-AndRestriction.patch then watch the previous test 
succeed.


4) Run vdb-depset-test.py to try it on your whole vdb (ParseErrors can 
be expected due to invalid syntax).




Actually, step 4 will not work without the attached patch that fixes a 
problem with the vdb multiplex repository.




After the DepSet and multiplex repository work mentioned above, I spend some 
time experimenting with bin/tests/build_installed_state_graph.py and was able 
to get the state_graph working correctly for most of the packages in my vdb 
(neglecting ParseErrors which I fixed by editing vdb *DEPEND files directly).

The first and last hunks of the attached patch fix a couple small breakages 
that are due to code changes elsewhere.  The middle hunk fixes a problem with 
block atoms that do not match any packages.  Previously, these atoms would not 
make it into the okay_atoms set which caused unresolved dependencies.

One other problem worth noting is that some DepSet conditionals may be 
evaluated incorrectly due to USE flag handling in portage.vdb.repository where 
USE flags are filtered to only include the ones listed in IUSE.  This causes 
the ARCH flag to be excluded (x86 in my case) and conseqent problems when the 
pkg.rdepends DepSet is evaluated.

Zac
Index: portage/graph/state_graph.py
===
--- portage/graph/state_graph.py	(revision 2326)
+++ portage/graph/state_graph.py	(working copy)
@@ -6,7 +6,7 @@
 import sets
 
 from portage.package.atom import atom
-from portage.restrictions.packages import OrRestriction
+from portage.restrictions.boolean import OrRestriction
 
 class StateGraph(object):
 
@@ -58,12 +58,19 @@
 all_atoms.union_update(atomset)
 			okay_atoms = sets.Set()
 			for atom in all_atoms:
+have_blocker=False
 for child in self.pkgs:
 	if atom.key != child.key:
 		continue
-	if atom.match(child) ^ atom.blocks:
-		okay_atoms.add(atom)
+	if atom.match(child):
+		if atom.blocks:
+			have_blocker=True
+		else:
+			okay_atoms.add(atom)
 		break
+if atom.blocks and not have_blocker:
+	# block atom that does not match any packages
+	okay_atoms.add(atom)
 			for choice in self.pkgs[pkg][0]:
 if choice.issubset(okay_atoms):
 	break
@@ -187,10 +194,7 @@
 	ret = sets.Set()
 
 	if isinstance(restrict, OrRestriction):
-		# XXX: OrRestrictions currently contain a single DepSet that contains
-		# the Or'd elements. This seems broken to me.
-		# -- jstubbs
-		for element in restrict[0]:
+		for element in restrict:
 			if isinstance(element, atom):
 newset = sets.Set()
 newset.add(element)