Re: [gentoo-portage-dev] .53, .54 and beyond...

[Jason Stubbs]

On Wednesday 07 December 2005 11:57, Marius Mauch wrote:
 On Wed, 7 Dec 2005 08:41:27 +0900

 Jason Stubbs [EMAIL PROTECTED] wrote:
  On Wednesday 07 December 2005 01:01, Marius Mauch wrote:
   On Tue, 6 Dec 2005 23:19:38 +0900
  
   Jason Stubbs [EMAIL PROTECTED] wrote:
If there's no solid opposition, Saturday I will put current trunk
into ~arch as 2.1_beta20051210.
  
   Well, I've already stated several times that IMO using a 2.1 branch
   is wrong (use 2.2 instead), but if I'm overvoted, so it shall be.
 
  As Brian stated, 2.2 being a version higher than 2.1 will have all
  the same expectations placed on it. From what I can see, 1% of users
  know anything about 2.1 so 99% would be wondering why there was a
  jump from 2.0 to 2.2. Do you have anything against 2.1 other than
  fearing that people will expect more from it than it will turn out to
  be?

 It isn't about expectations.

Ok, I misunderstood your previous posts on this topic then.

 I just think it's bad engineering to use the same version prefix for
 two rather different codebases. ... After all, wasn't engineering the reason 
 why we're going to increase the minor?

I don't understand where the conflict comes in between the two. Internally, 
the old 2.1 has been known as HEAD, trunk and now 2.1-experimental. 
Externally, it's been known as 2.1.0_alpha20050718. The set of new features 
available in 2.1.0_alpha20050718 are pretty much all available in current 
trunk as far as I know... You'll need to explain the issue in a little bit 
more detail.

  Really, the bottom line is that regardless of what the response was
  when you asked about portage keywording, if all the arch teams had
  confidence in what we thought 2.0.53 would have been stable a long
  time ago. On the surface the only benefit is extra testing (which has
  already payed off) but it also allows others to take an active hand
  in the quality of portage as well as strengthens the communication
  channels.

 Ok, but it still doesn't really have anything to do with arch teams,
 just general QA.

True, but currently there's no general QA team for coordinating the stability 
of the tree in general. Instead, this has been left up to the individual arch 
teams (which is a little strange/disorganized) so 


 Also I didn't mean to criticize you, just stating that this option exists.

Isn't it your responsibility to? ;)

  I can't tell if you followed what I said in my last email so I'll
  reiterate. Trunk will go into ~arch on Saturday. 2.0.54 will go out
  (also in ~arch) two weeks after that with the two fixes and include
  the cache rewrite based on the opinion of a broad range of users
  (rather than just the noise makers). SHA1 will of course also go in
  based on how it is voted.

 Ehm, what's the point of having .54 in ~arch after trunk is in
 ~arch? You won't get much testing that way as ~arch users would
 already use trunk and stable users likely won't know about .54 ...
 (typical visibility problem)

The visibility problem is exactly why I'm suggesting it be done that way. 
Neither ~arch users nor arch users get needless bumps and testing of trunk 
doesn't get held up at all. .54 would be .53 + selective patches from trunk 
hence all its parts will have had extensive testing. The whole would only 
need a minimal amount of testing by those marking it stable before doing so.

--
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)