Kent Fredric <[email protected]> wrote: >> >> 1. The virtual does not even exist :) >> > > Nope, it does. Its just called =virtual/perl-Term-ANSIColor-4.20.0
In this case the virtual is buggy, becaues it does not contain || ( dev-lang/perl-5.18* ... ) Due to this, this particular example is not so ideal: I wanted to have an example where the stable virtual/perl-... version is higher than the one provided by (stable) perl. (This is then not the case once the virtual got fixed and perl-5.18 gets stable.) Please replace this example by one for which this is the case, say virtual/perl-Digest-MD5 and assume that I want an ebuild for a package for which *any* version of perl-Digest-MD5 would be sufficient. In this (now hopefully correct) example, if I do not write something like RDEPEND="|| ( >=dev-lang/perl-5.12 virtual/perl-Digest-MD5 )" or RDEPEND="|| ( =dev-lang/perl-5.12* ... virtual/perl-Digest-MD5 )" but instead only the "natural" RDEPEND="virtual/perl-Digest-MD5" I would currently pull in unnecessarily perl-core/Digest-MD5-2.520.0 or perl-core/Digest-MD5-2.530.0 (depending on whether the user is using e.g. ~amd64 or amd64). What I meant was that one might have the strange idea to use as a "workaround" for this problem the dependency RDEPEND="=virtual/perl-Digest-MD5-2.510.0-r2" but this would be a very bad idea many reasons, in particular: >> 2. It would collide with ebuilds depending on other versions. > > Nope, it would only collide in the case other ebuilds depended on a > specific version This is what I mean by "ebuilds depending on other versions". The above "workaround" would unnecessarily block ebuilds which contain RDEPEND="... >=virtual/perl-Digest-MD5-2.520.0 " > This is seen as a "feature" I agree. I just wanted to point out why the "workaround" is not really a workaround of the problem but would be just a very bad idea. >> 3. This version is only reasonable if perl-5.16 is the >> perl version which the user has installed > > And when perl 5.18 hits tree [...] you'll > need to change your dependency string in your package Exactly: This is what you would have to do, and which is not solved by the current virtual/... approach unless you accept pulling in unneeded dependencies. > Virtuals are much more convenient here More convient than putting into the ebuild, but at the cost not only of maintaining the virtuals but also of installing duplicate packages on the user's system. Take the above (hopefully correct) example that you have the "natural" RDEPEND="virtual/perl-Digest-MD5" Although *any* perl version containing this module would be sufficient, this dependency will install for a user with unstable keywords in addition perl-core/Digest-MD5-2.330.0, because this is the currently highest available version of the virtual and not satisfied by any perl version. (Similarly for the user with stable keywords, it will install currently unnecessarily perl-core/Digest-MD5-2.320.0 and when perl-5.18 hits the stable tree, it is rather likely that also >=virtual/Digest-MD5-2.330.0 is stable so that the user has unnecessary duplicate versions installed throughout.) > (Actually, thats a bug still, because corelist -a says 4.20.0 should be > available in 5.18 In my local overlay, I have a list of ~30 more such virtual/perl-* for which I have fixed dependencies (though maybe I have falsely translated the version numbers). This does not belong to this mailinglist, so if I you are interested in the virtual list or if I should open a bug, drop me a pm. Both suggested solutions (eclass or dev-lang/perl-... with useflags) would avoid all of these problem: You have to update only one list of packages for every perl version, not update every single virtual/... and, more important, the dependencies would not pull in unnecessary packages for the user.
