e.g. for the last update it pulled in perl-core/Module-CoreList:0 virtual/perl-Module-CoreList:0 while virtual/perl-Module-CoreList-3.30.0 is stable it has a depstring like so: RDEPEND=" || ( =dev-lang/perl-5.18* ~perl-core/${PN#perl-}-${PV} ) !<perl-core/${PN#perl-}-${PV} !>perl-core/${PN#perl-}-${PV}-r999 " But there is no perl-core/Module-CoreList-3.30.0 whatsoever, so this results in a block. a) your ebuilds shouldn't depend on non-existing packages in the first place, even if it's within a || () string b) why does perl-cleaner pull in the non-virtual anyway?
No.
(In reply to Andreas K. Hüttel from comment #1) > No. No, what?
(In reply to Andreas K. Hüttel from comment #1) > No. I'm sorry, but this is not the right way to communicate on a bug tracker. I'm not sure if you just had a bad day or if you are provoking on purpose, but you have to explain why a bug is invalid.
I believe that this is simply not easy to fix, and that the latest perl-cleaner gives a warning in this scenario with a technique for attempting to solve this problem. That is, if you already have a copy of perl-core/Module-CoreList installed, that this problem may be *really* due to something else in your VBD/Worldfile pulling the perl-core/Module-CoreList unilatterally, even though you have =perl 5.18. Which means even *if* perl-core/Module-CoreList-3.30.0 existed, it wouldn't solve this problem, it would just be invisible, as it would pull perl-core/Module-CoreList despite being satisfied by 5.18. =~ - Perl Cleaner tells you now how to make this problem go away. - If you followed those steps and you still have a problem, please report back with more context.
good explanation ^
(In reply to Kent Fredric from comment #4) > > Which means even *if* perl-core/Module-CoreList-3.30.0 existed, it wouldn't > solve this problem, it would just be invisible, as it would pull > perl-core/Module-CoreList despite being satisfied by 5.18. > I consider this an ebuild bug. Although it seems to be technically allowed, I think depending on non-existing versions in any kind of depstring (except version ranges ofc) should be banned by poliy. The problem being invisible wouldn't matter if perl-core/Module-CoreList-3.30.0 existed (in stable arch ofc). The next depclean would solve it.
(In reply to Mikle Kolyada from comment #5) > good explanation ^ Looks rather like WONTFIX or CANTFIX to me. It's a usability issue, so still a valid bug.
"I think depending on non-existing versions in any kind of depstring (except version ranges ofc) should be banned by poliy." Its kind-of an issue with how the versions happen upstream. Sometimes they'll get released "in perl" prior to being able to be shipped via perl-core/* , and other times they'll happen the other way around. Sometimes they might never arrive in a form we can ship via perl-core/*. And this adds maintenance burden for virtuals due to how many we have of them. So the *less* virtual editing we have to do, the better. And thus, the virtuals have a mostly consistent syntax for which, some point to things that don't exist yet under the assumption they might eventually. ( Which *should* be fine, because portage should simply ignore they exist in a conditional and choose between one of the options that exists. Of course, what portage "should do" and "does" appears to differ quite frequently. ) I'm all for adding perl-core/Module-CoreList-3.30.0 to tree, its just extra time and effort somebody has to put in
(In reply to Julian Ospald (hasufell) from comment #7) > (In reply to Mikle Kolyada from comment #5) > > good explanation ^ > > Looks rather like WONTFIX or CANTFIX to me. It's a usability issue, so still > a valid bug.
