On Thu, Nov 06, 2003 at 10:24:05PM -0800, Joe Buck wrote: > I'm trying to figure out the reason why orbit2 is blocked from testing, > see > > http://bjorn.haxx.se/debian/testing.pl?package=orbit2 > > I understand the problem in principle: there is/are some package/s that > needs the older version of orbit2, and the other "uninstallable" > packages depend on these. Ideally, though, there should be a way > to figure out some minimal set of packages that is causing the > conflict, rather than displaying a set of 79 and a set of 50. > > Is there any way to figure things like this out? And is there any > way to fix Bjorn's script to show such problems more clearly?
Right now, you figure this out by talking to the RM or one of his assistants, I'm afraid; debian-release is a good contact address. Björn's script just reformats the output of update_excuses.html and update_output.txt, and making that more explanatory would take a good deal more CPU power which isn't really available. (The script which computes all this stuff is already very resource-intensive.) Library changes often require what we call a "hint", where a human tells the testing script to ignore the fact that e.g. orbit2 breaks lots of things for a moment, and to see if going round and upgrading other packages based on orbit2 will get the number of uninstallable packages back down to the level it was before trying orbit2. This is very difficult to automate because you might have to try hinting an arbitrary number of packages at once which are all interdependent: five is the highest number I've ever seen needed (lcms, libmng, libwmf, imagemagick, plotutils). Last I checked, which was a few days ago, the last piece needed to make a hint for orbit2 work is to get the current version of nautilus to build on m68k. Cheers, -- Colin Watson [EMAIL PROTECTED]
