Given the following dependency graph: X -> help2man[nls] -> dev-perl/Locale-gettext -> perl People upgrade perl from 5.20 to 5.22 or 5.22 to 5.24 Upgrading perl from 5.22 to 5.24 makes Locale-gettext "transiently uninstalled", and as such, nothing that depends on it ( help2man ) can be used until it is reinstalled. Locale-gettext will continue to be considered "uninstalled" ( and help2man is thus broken ) until either portage's SLOT REBUILD percolates, or the user manually resolves the problem with perl-cleaner. However, SLOT REBUILD clearly doesn't percolate regularly enough to avoid problems with installed packages, as people regularly are entering circumstances where they end up building X before help2man works again, because SLOT REBUILD for Locale-gettext is scheduled, but help2man is *not*, and Locale-gettext is scheduled too late to be useful. I suspect Portage considers help2man "working", because its installed, so the subgraph X -> help2man May be considered "satisfied", despite the fact help2man is secretly broken, and portage can't tell. Traditionally, the answer here has been "suck it users, run perl cleaner and try again", but given we have slot rebuilds, and given this problem is a noteable issue that affects not *just* help2man, but everything like it, we need a better solution.
*** Bug 592102 has been marked as a duplicate of this bug. ***
*** Bug 592850 has been marked as a duplicate of this bug. ***
*** Bug 556752 has been marked as a duplicate of this bug. ***
*** Bug 559660 has been marked as a duplicate of this bug. ***
I wonder if this is related to the --with-bdeps option of emerge? By default, portage does not include DEPEND when computing the set of packages for a @world upgrade. It only gets considered if the requirements are not already met by an installed package. That means help2man doesn't get pulled into the depgraph by default.
*** Bug 552194 has been marked as a duplicate of this bug. ***
*** Bug 592554 has been marked as a duplicate of this bug. ***
(In reply to Mike Gilbert from comment #5) > I wonder if this is related to the --with-bdeps option of emerge? > > By default, portage does not include DEPEND when computing the set of > packages for a @world upgrade. It only gets considered if the requirements > are not already met by an installed package. That means help2man doesn't get > pulled into the depgraph by default. How is that relevant? help2man RDEPENDS on Locale-gettext ( and DEPEND=RDEPEND ) In an example failure case bug #592850, libmp4v2 is selected for recompile. libmp4v2 states it needs help2man for DEPEND So by extension of logic: - help2man is required - all of help2man's RDEPEND's are required - one of help2man's RDEPEND's is deemed "broken" by way of subslot missmatch - therefor help2man's RDEPENDS are deemed unsatisfied - therefor libmp4v2 should not be compiling. Unless of course, whoever implemented the logic assumed subslot missmatches would continue to work due to pkg-preserved, and assumed it was ok to build stuff known to be broken... But that would only be a fine assumption with C dependencies, and only on PMSs with pkg-preserve, really doesn't work for Perl.
(In reply to Kent Fredric (IRC: kent\n) from comment #8) > How is that relevant? It's a guess, based on prior experience when using portage. I would suggest you ask zmedico about it.
This is probably a form of bug 199856, and bug 463976 is a related issue that makes the problem worse when circular dependencies are involved.
*** Bug 593350 has been marked as a duplicate of this bug. ***
*** Bug 616116 has been marked as a duplicate of this bug. ***
*** Bug 637924 has been marked as a duplicate of this bug. ***
*** Bug 660744 has been marked as a duplicate of this bug. ***
*** Bug 689696 has been marked as a duplicate of this bug. ***
*** Bug 782058 has been marked as a duplicate of this bug. ***
Edited for brevity: [01:41:33] <sam_> dilfridge: but I'm wondering if it's worth some hack like grepping for 'Locale::gettext' or the full error string in build logs and suggesting the user run perl-cleaner --all if present [01:41:40] <sam_> because this seems to be happening a lot more frequently at the moment [01:59:02] <sam_> longer string is better to avoid false positives but we can probably some up with something [01:59:14] <sam_> I appreciate it's a pretty gross bandaid [01:59:40] <sam_> It's just that as a user, I'm not sure it's obvious what to do if you hit it [01:59:53] <dilfridge> it's absolutely non-obvious [02:00:01] <dilfridge> unless you've seen the bug a dozen times [02:00:04] <zmedico> what's the problem? [02:00:35] <sam_> quite a few people (more than usual) seem to be hitting bug 782058 [02:00:58] <sam_> in this case, someone was just building grub and had it, but we've had quite a few bug reports recently [02:02:30] <sam_> http://ix.io/3n3p [02:04:36] <zmedico> if you have an update with slot operator rebuilds, then that triggers it, as usual for things that block bug 689644 [02:05:10] <zmedico> and bug 756199 would be the lowest hanging fruit in this area
*** Bug 802144 has been marked as a duplicate of this bug. ***
*** Bug 834609 has been marked as a duplicate of this bug. ***
*** Bug 835002 has been marked as a duplicate of this bug. ***
*** Bug 857129 has been marked as a duplicate of this bug. ***
