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

Re: A question about update-excuses (was Re: testing is broken)



Anthony Towns <aj@azure.humbug.org.au> writes:

> On Wed, Apr 11, 2001 at 05:14:23PM +0530, Ganesan Rajagopal wrote:
> > ---
> > * python2 2.0-6 (new) (optional) (low)
> >     * Maintainer: Gregor Hoffleit <flight@debian.org>
> >     * python2 uploaded 48 days ago, out of date by 38 days!
> >     * out of date on m68k: python2-base, python2-dev, python2-tk, python2-xmlbase (from 2.0-4) (but m68k isn't keeping up, so ignoring this problem)
> >     * there are up to date bins in m68k also
> >     * valid candidate (will be installed unless it's dependent upon other buggy pkgs)
> > ---
> > However, there doesn't seem to be any real package called python2; instead
> > python2-base provides python2. None of the other packages from the python2
> > source seem to depend on "other buggy pkgs". There must be an easier way to
> > figure to figure this out :-).
> 
> It's just plain difficult to figure out. The only ray of light at the moment
> is the update_output.txt page. In python2's case, down towards the bottom,
> it says:
> 
> 	python2: m68k: idle-python2 python2-examples python2-regrtest
> 
> which means python2 wasn't included because it made some packages uninstallable
> that are currently installable in testing; in this case it's idle-python2,
> python2-examples and python2-regrtest on m68k.
> 
> Looking at the m68k Packages files for unstable, we see these packages
> dependencies look like:
> 
> idle-python2 Depends: python2-tk (>= 2.0-6)
> python2-examples Depends: python2-base (>= 2.0-6)
> python2-regrtest Depends: python2-base (>= 2.0-6)
> 
> python2-tk and python2-base are out of date on m68k and can't meet those
> dependencies though. Ain't arch: all package skew great? There's a similar
> problem with perl.

How hard would it be to make the excuses file tell more about what's
blocking a particular package ?

For example, five of my packages have been stuck in unstable
(utah-glx, aleph, xwave, am-utils, and amd), with am-utils and amd
being very dearly needed in testing (testing's amd does not work, and
I keep getting bugs about that).

They all have simple dependencies that are all in testing already,
yet some of them have been stuck in unstable for more than 2 months !

Phil.



Reply to: