The various java ebuilds now PROVIDE what is virtual/jdk-${PV} and/or virtual/jre-${PV}. Likewise ruby-cvs ebuilds PROVIDE virtual/ruby-${PV}. It seems this is unnecessary and will actually break portage on an unmerge. It is unnecessary in these cases because when a versioned virtual appears in a DEPEND, portage will first match the unversioned virtual to a package and then compare that package's version(s) against those specified in the DEPEND. Cases where it might be necessary are when the packages involved have a different ${PV} for the same "version" of a virtual. These cases should be addressable by including the "version" in the virtual name. For example, virtual/foo1 and virtual/foo2. Java and Ruby people, please explain the necessity if this logic is incorrect. It breaks portage during an uninstall of these packages. Portage checks /var/cache/edb/virtuals against /var/db/pkg/*/*/PROVIDE and will never find a match and thus the virtual is not removed even if all providing packages are uninstalled. The enhancement request is for repoman to check the validity of PROVIDE (there was one other case where PROVIDE actually listed real packages) and by extension the ability to access the PROVIDE variable through portdbapi.
ruby-cvs doesn't provide virtual/ruby-${PV} but dev-lang/ruby-${PV}. (we know you should provide only virtuals, but we didn't do so because we need version with virtuals just as you described) We need to distinguish between ruby-1.6, ruby-1.8 and ruby-1.9 (some packages use ruby18 feature while other packages use ruby19 feature, etc). Surely we can do it by adding virtual/ruby16, virual/ruby18 and virtual/ruby19 but if we do so how we can write an ebuild depending on simply ruby? Should we write DEPEND="|| ( virtual/ruby16 virtual/ruby18 virtual/ruby19 )" or DEPEND="|| ( dev-lang/ruby dev-lang/ruby-cvs )"? Or, how can we express something depending on ruby-1.8? If we are not allowed to provide non-virtuals nor versioned virtuals, we should write it as DEPEND="|| ( virtual/ruby18 virtual/ruby19 )" or DEPEND="|| ( >=dev-lang/ruby-1.8 >=dev-lang/ruby-cvs-1.8 )" but the logic of former example is flawed as we need to add every new virtuals when there will be new ruby major release (well, we could do so, but...). Moreover, if we are to prohibit versioned virtuals, what's the point of having SLOT? If we should include version in package's name when versioned virtual is appropriate, it's the same in SLOT IMHO. So my point is portage should support either versioned virtuals or non-virtual PROVIDE. (non-virtual PROVIDE seems to work atm - it's not recommended though)
To give an example of how I believe the ebuilds should be implemented: dev-lang/ruby-1.6.8-r3:PROVIDE="virtual/ruby" dev-lang/ruby-1.8.0-r1:PROVIDE="virtual/ruby" dev-lang/ruby-cvs-1.8.1:PROVIDE="virtual/ruby" dev-lang/ruby-cvs-1.9.0:PROVIDE="virtual/ruby" dev-ruby/soap4r-1.4.8.1:DEPEND=">=virtual/ruby-1.8.0_pre* ..." dev-ruby/soap4r-1.5.1.2:DEPEND="<virtual/ruby-1.8.1 ..." soap4r-1.4.8.1 can be satisfied by ruby-1.8.0-r1 or either of the ruby-cvs versions. soap4r-1.5.1.2 can be satisfied only by either of the ruby versions. The only time that this would break down is if there was a whizbang-ruby-10.5 which was just an implementation of ruby-1.8.
okay, i'll fix them as you requested (your proposal seems to work for existing ruby ebuilds).
Your solution won't work, Jason. kaffe is at version 1.1.4 and provides virtual/jdk-1.4. If we implemented, as you suggest: kaffe-1.1.4: PROVIDE="virtual/jdk" blackdown-jdk-bin-1.4.1: PROVIDE="virtual/jdk" anyjavaebuild: DEPEND=">=virtual/jdk-1.4" Then the blackdown-jdk-bin would be installed, despite the user's clearly stated preference (by explicitly installing kaffe) that he prefers kaffe. But then again, you've observed this yourself with whizbang-ruby-10.5:) Currently, this is only a problem for kaffe, but it actually goes for all open-source VMs: They do not follow the sun versioning scheme. So it will crop up as we add more open-source VMs to dev-java. Furthermore, we also need to be able to depend on virtual/jdk-1.4.2, not just virtual/jdk-1.4, as there are sometimes minor tweaks happening at the patch version level that prevent some packages from running/compiling. Example at hand: eclipse-sdk-3.0.0_pre8 and _pre9 will not reliably compile and run with 1.4.1-derived VM, so we need to DEPEND on something that provides 1.4.2 or newer.
Fixed on or before 2.0.51.22-r1
Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened.
