<rant> i'm more than a little annoyed w/ the libperl_rebuilder script. 1) decide which packages should be rebuilt 2) unmerge those packages 3) die w/ error about inability merge masked packages 4) leave system w/o vim to edit files to unmask problem packages. This not a major problem, but having to resort to nano just because the script removes things before checking to see if it can do all the followup steps seems silly. it died because artwiz fonts were masked... can't there be an 'emerge -p <packages>' just to make sure they can do it? </rant> i'm okay now.
This was fixed this morning :) It annoyed me to once it was in use. * Now, rather than unmerge packages, it merely tries to emerge over them (a somewhat saner approach, IMO). * The mask error checking has been copied up the chain of failure points so that it can tell you that there is a masking error earlier on. * As a side not, vim would not have worked for you anymore. If it detected your vim, that meant your old vim was compiled against libperl.so and therefor would have died if you tried to use without remerging it anyway. * I can't account for you emerging packages without setting your ACCEPT_KEYWORDS. However, the script now dies promptly if it sees a masked ebuild that you aren't in a position to emerge (such as your example below). * One other addition made today is that it now additionally checks for packages that were emerged without compiling against libperl, that aren't part of dev-perl, but that nonetheless place files in /usr/lib/perl. Just in case that was at the back of your mind.
And the dang thing can run forever?? It's been 5 times so far that it's rebuilt HTML::Parser, which I noticed because every time it does it stops to ask me: "Do you want decoding on unicode entities? [no]" Which is fine to ask once or twice, but I check the log and it's rebuilding everything five times because each time through dev-perl/gtk-perl-0.7008-r4 fails.... Ah, it's finally given up, having concluded that rebuilding everything 5 times is not going to make gtk-perl build correctly. And when I do "emerge -up gtk-perl" I see that this isn't the current version - I haven't done another "emerge sync" since starting the script (and I _did_ do an "emerge -u world" after the last sync) - so what it's trying to do playing around with an obsolete gtk-perl I've not the slightest idea. Now, after a fresh sync, if I do "emerge -up world" I get: These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] net-misc/ntp-4.1.1b-r4 [4.1.1b-r3] But if I do "emerge -up gtk-perl" I see: These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] dev-perl/XML-Writer-0.4-r2 [0.4-r1] [ebuild U ] dev-perl/XML-Parser-2.31-r1 [2.31-r0] [ebuild U ] media-libs/libpng-1.2.5-r2 [1.2.5-r1] [ebuild U ] media-libs/gdk-pixbuf-0.21.0 [0.20.0-r0] [ebuild U ] dev-perl/gtk-perl-0.7008-r9 [0.7008-r4] which shows gtk-perl being recognized as being in an updated version when I request it directly, but not showing up in "world" updates. Huh? Should I suspect other dev-perl stuff is now also not registered as "world"? And the current version does build okay.
It runs four times on the moduels total. If you reran it any point, it will show up more in your logs. It doesn't record them in your world file because it does a --oneshot. This is so we don't add packages to your world file that you didn't ask to be there to begin with. HTML::Parse should have been fixed. I will see why it hasn't been. That should be a seperate bug report though (the problem is with HTML::Parse, not the rebuilder). Your questions are starting to veer into portage issues, not the libperl_rebuilder. Is there an actual bug to report with the libperl_rebuilder??
What is the actual purpose to rebuilding the modules (now 3) times? If it is to retry failed modules, why not just retry failed modules? Or how about this approach: each time through, count the number of modules that failed to emerge. If the number is 0, stop. If the number is less than last time through, this indicates progress is being made, and do another loop. If the number is the same as the previous time through, no progress is being made so stop.
Actually, it's not that easy. A perl module will install successfully even if it's deps are not met - it will instead silently (via perl) complain that a prerequisite is not met, but will continue to install the module. So the ebuild won't fail directly.
There doesn't seem to be an actual libperl_rebuilder bug here, per se. Closing.
got "unmarked" as closed
