[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Trying to understand "updating orbit2 makes 79 packages unintallable ..."

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,

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.


Colin Watson                                  [cjwatson@flatline.org.uk]

Reply to: