On Monday 14 March 2011 17:14:25 Willie Wong wrote: > Hi list, sorry for the nondescript title. Let me described what > happened. > > I ran `emerge --update --deep world' over the weekend which updated > app-text/poppler: > > Sat Mar 12 22:00:46 2011 >>> app-text/poppler-0.16.3 > > Today I found out that a whole bunch of packages got broken, and so I > ran `revdep-rebuild -p'. To my surprise, revdep-rebuild wants to > downgrade to app-text/poppler-0.14.5. That's odd, I thought. > > So I ran `emerge --pretend --oneshot --verbose --tree' against the > list of packages produced by revdep-rebuild, and it displays near the > bottom that poppler-0.14.5 is a dependency of luatex-0.65 which is a > dependency of texlive-core-2010-r1. Okay. So I thought that one of > those two packages have an explicit dependency on a lower version of > poppler. And I thought I want to file a bug about that. > > Digging into the ebuilds for luatex and texlive, I can't find any > reason why they would require poppler-0.14.5, and not 0.16.3. So after > puzzling about it for 20 minutes, I did the stupid thing, and tried > > `emerge --oneshot --pretend luatex texlive-core' > > and lo-and-behold, the poppler dependency does not appear! > > Then combing through the list of packages one-by-one, I finally found > (on the second-to-last package that I tried) that the culprit is > in fact python-poppler. > > ------------------------------------ > > Now, two questions: > > (a) Should this be considered a bug in portage? The presented > information from `emerge --pretend --tree' is misleading to which > package is actually causing the downgrade request.
I don't think this is a bug in any meaningful sense of the word. It's a side- effect of having a large dependency graph: Many packages depend on poppler, so the dev has several choices: a. print the first one found. Due to the way such things (searching data trees in memory) work, this will usually be a different one each time the command is run b. print the last one found. This is a) upside-down with the same problem c. Print a random one found. Well, it is an option, but .... doh ;-) d. Print the whole damn lot. This has the especially nasty side effect of producing vast amounts of output with even vaster amounts of bug reports and, believe it or not, vaster numbers of pissed off users e. Determine (later) the actual version that will be installed then go back to the data tree, modify it in place, then print the output. e) sounds wonderful. I suggest you try implement it. You will rapidly discover why it is seldom implemented. Conclusion: This shit is hard. It's a marvellous way to make the most people the most unhappy in the shortest possible time. > (b) Is there a way to have found that python-poppler was the culprit > without running `emerge --pretend' on each of the list of 16 packages? Perhaps "emerge -e -t -p luatex texlive-core" ? p.s. What I wrote looks tongue-in-cheek. It isn't really. I have very similar issues with code I admin and maintain, with similar results. I too decided to take the lazy route out and try be right most of the time and screw it when it isn't perfect. -- alan dot mckinnon at gmail dot com
