Re: >2000 packages still waiting to enter testing, > 1500 over age
On Thu, Apr 17, 2003 at 05:21:41PM +1000, Paul Hampson wrote:
> Anyway, now that I've done that... back to your actual interest:
> ocaml is also being recurred:
> i386: libpgsql-ocaml-dev, libsdl-ocaml, libsdl-ocaml-dev, ocaml-libs
>
> From sources:
> libpgsql-ocaml <== Unstable version breaks with postgresql-dev
> ocamlsdl <== broken on m68k?
No, it is a valid candidate. The problem is
that it depends on sdl-mixer1.2 which
depends on libvorbis.
> meta-ocaml <== Unstable version breaks with something or
> breaks a single package when it fixes itself.
This is just a meta package which depends on the ocaml compiler suite
(ocaml-core) or ocaml libraries (ocaml-libs). I think the problem with
it is because it depends on libsdl-ocaml-dev and libpgsql-ocaml-dev.
> A problem here is that when a package hits that spot where it's
> being installed in a recur'd loop, and it is accepted but still
> not installable, the script doesn't tell you _what_ is still
> breaking it. And the script can't tell the difference (at least
> in the output) between this and a package that breaks a single
> dependancy in all archs where it becomes installable.
>
> Maybe it should handle broken packages staying broken in some
> other way? Or at least report it differently? Give the data of
> both an accept and a reject (Breakage counts and the list of
> packages which make up the difference in the pre and post counts...
> and some indicator why (if it's the case) this package stays
> broken on being sarged.
Well, i personnaly think that in some case it would be much simpler to
_remove_ the packages from testing, and let the new versions enter
testing as they can. If this where to happen in the libvorbis case, then
the new libvorbis will enter testing, together with all the packages
that are already ready, and the ones which are not would simply not be
in testing until they are fixed. In the ocaml case, same, we would
remove an obsolet version of ocaml that nobody uses anyway from testing
(even woody has a newer version now) and have the new version enter
testing without problems, with just the problematic packages being hold
back.
This would make more sense in a release preparation point of view,
because the aim of testing is to prepare sarge, and the aim of sarge is
to ship with the newer packages. The sooner we can get the packages
which are supposed to ship with sarge into testing, the more we will be
able to test sarge prior to the release.
Also, this is a decision the the maintainer (or group of maintainers) of
the related packages are best informed to make, and when it is made,
then the ftp-masters (or whoever is supposed to do it) should follow
suit and not let the request for removal bug sitting in the BTS
unanswered. If they don't agree or whatever then they should say so, but
just ignoring the issue is lack of respect of our fellow maintainers.
Even a 'we don't have time for this right now' kind of aknowledgement is
better than letting people sitting in the dark.
As said, in the ocaml case, nobody uses the version actually in testing,
they use either the woody backport from Stefano, the actual unstable
packages, or build their own packages by hand. And as said, i get weekly
inquiries about what is going on.
Friendly,
Sven Luther
Reply to: