Re: Unofficial Debian 'testing' FAQ (was Re: Packages in queue forwoody?)
Hi,
On Wed, 12 Dec 2001, Adrian Bunk wrote:
> On Wed, 12 Dec 2001, Richard B. Kreckel wrote:
> > ??? Maybe I'm blind but I still cannot find any description what...
> > skipped: cln (0) (150+4)
> > got: 167+0: a-40:a-33:h-49:i-45
> > ...is supposed to tell me. It doesn't seem to be explained in Jules'
> >...
>
> the next line is the important one:
>
> skipped: cln (0) (150+4)
> got: 167+0: a-40:a-33:h-49:i-45
> * i386: ginac-cint, libginac-dev
>
> This means that when cln will go into testing ginac-cint und libginac-dev
> will become uninstallable in testing on i386 (note that the architectures
> are checked in alphabetical order and only the problems on the first
> architecture with problems are shown).
>
> > guess, but what are these funny numbers?)
>
> The "got" line:
> These are the number of problems in testing on the different architectures
> (until the first architecture where a problem is found - see above). The
> "i-45" means that if cln would go into testing there would be 45
> uninstallable packages on i386 (if you look at the entries above and below
> cln you see that there are currently 43 uninstallable packages in testing
> on i386).
>
> In the "skipped: cln (0) (150+4)" line:
> - still 150 packages to go through after this package until this run
> through all packages is completed
> - already found 4 packages in this run through all packages that won't be
> planned to be upgraded because they would break dependencies
>
> Note that there are several runs through all packages in one testing run.
>
> I can't guess the meaning of the "(0)" like I guessed the meaning of the
> other figures because it seems to be always 0 in the latest update_output.
Ah, thanks a lot for this helpful, uhm, exegetical analysis.
The question that now comes up is what can developers do in order to
unclog a congestion like this, if it is one. The two depending packages
in testing are not going to go into testing anyways since the first one
seems slightly buggy anyways and the second doesn't build any more (since
libreadline was updated to 4.2a) but there already is a fixed version in
unstable which by the would work with the cln version that is on hold
since 32 days. But maybe this is going to be resolved automatically as
soon as the ten days for these two packages are over???
While I appreciate the benefits of a formal system for updating decisions
I am slightly concerned about such congestions that sometimes can leave
developers clueless about how to solve their packaging issues.
Regards
-richy.
--
Richard B. Kreckel
<Richard.Kreckel@Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
Reply to: