My eix output looks like this: Hugin etc # eix perl-core/Storable [U] perl-core/Storable Available versions: 2.390.0-r1 ~2.450.0-r1 Installed versions: 2.390.0(11:25:40 PM 11/17/2013) Homepage: http://search.cpan.org/dist/Storable/ Description: The Perl Storable Module Hugin etc # eix virtual/perl-Storable [U] virtual/perl-Storable Available versions: 2.390.0 2.410.0-r1 ~2.450.0 ~2.490.0 Installed versions: 2.390.0(10:55:21 PM 11/17/2013) Description: Virtual for Storable I'm sure a number of other packages have this situation too, as it causes a number of blocked packages when I run perl-cleaner --all: http://pastebin.com/PxpEGqfp perl-cleaner tells me to unmerge perl-core packages and then update perl virtuals. I am unwilling to unmerge a bunch of my existing perl packages (ex: perl-core/Storable-2.390.0-r1), because it looks like this inconsistency in the portage tree would prevent them from merging back in later. I would like to know just what the implementing package is supposed to be for (virtual/perl-Storable-2.410.0-r1). After a bit of searching the internet, I have come to the conclusion that this is a nontrivial query. I tried looking at the .ebuild for the virtual: vim /usr/portage/virtual/perl-Storable/perl-Storable-2.410.0-r1.ebuild ... and it isn't very clear to me, as I am not acquainted with RDEPEND's syntax. So I am left with something that looks asymmetrical and bug-like: virtual/perl-Storable-2.410.0-r1 exists but perl-core/Storable-2.410.0-r1 does not. I have also read this forum thread where someone had a similar (if not same) issue: https://forums.gentoo.org/viewtopic-t-997152-postdays-0-postorder-asc-start-0.html The poster seemed to solve it by merging @world (somehow). In my case, @world also has a number of blocks, so I have no idea if that would actually work for me (under better circumstances). Trying to merge these packages with --with-bdeps=y doesn't seem to change anything, either. As a consequence, a number of my perl-based packages are not operable, and I am unable to proceed with updates. Please help! And thank you for all of your diligent efforts, ebuild maintainers. Here are some versions of relevant tools installed on my system: sys-apps/portage-2.2.8-r2 app-admin/perl-cleaner-2.16 dev-lang/perl-5.18.2-r2
=dev-lang/perl-5.18* should cover that: perl-Storable-2.410.0-r1.ebuild : RDEPEND=" || ( =dev-lang/perl-5.18* ~perl-core/Storable-2.410.0 ) || ( ... ) means any one of the atoms will satisfy the same dependency.
"Virtuals" say "is this thing provided somehow". So as long as the virtual has one of the two, the virtual is satisfied, and any dependencies are fullfilled. Hence, removing perl-core/Storable doesn't actually deprive you of a storable implementation, as dev-lang/perl will fullfill that. Hence, the advice to remove redundant perl-core/* entries to allow the virtual to be satisfied by dev-lang/perl || ( ... ) Says "One of these things must exist" !< x !> y Says "If x exists and it is older than X, remove it" and "If y exists and its newer than Y, remove it". ( Because having perl-core/THING-5.10 and virtual/perl-THING-5.1 is a very bad thing to have. Either the versions should be the same, or the perl-core/ one should be missing )
Thanks, both of you! Now I can unmerge those packages with some amount of confidence. That solves the problem for me, specifically. Now for solving the problem in general: Is there some way we can prevent migration of virtual package implementations from causing spurious blocks? This might be moving into "enhancement" territory, but I feel it is important. These kind of things are frustrating for the user, and it generates forum threads and bug reports that developers have to spend time on. In this instance of perl-core/* vs virtual/perl-*, it seems like something that portage should have been able to figure out on its own. And if that's too much to ask, then could we at least have a tool for listing the packages that can be used as implementations for a particular version of a virtual package? The task of listing implementations seems like it could be done correctly and definitively from within a portage tool that has an intimate comprehension of ebuild syntax/semantics, yet would be error-prone and taxing for an uninformed user. Having at least this kind of tool would be incredibly helpful. Thoughts?
