On Sat, Oct 29, 2005 at 05:07:49PM -0400, Nathanael Nerode wrote: > I expect that gcc-4.0 blockages are only going to increase as > time goes on, because some maintainers can't seem to stop making > uploads, so the faster this can be done, the better. > Now, it's true that no matter what we do, a bunch of stuff will be stuck > behind binutils/glibc/gcc-4.0, which is going to take a while, probably > a month or more. (It's not reasonable to force them through given the > build failures and grave bugs in binutils and glibc.) And without forcing them, this: > force kdeaddons/4:3.4.2-2.1 will not work because a force hint will not cause consideration of packages which britney eliminates due to dependencies. Which means the only way to force kdeaddons is by also forcing gcc-4.0, binutils, and glibc. Forcing binutils will succeed, because its out-of-dateness on some architectures won't render anything else uninstallable; glibc will also succeed for the same reason; and I suspect that gcc-4.0 will follow as well. We don't want this -- these packages are all *much* buggier than the versions in testing right now, and it definitely doesn't help our users to push them into testing. And kdeaddons can't be removed from testing, or be left broken in testing, without also breaking the kde metapackage. Actually, the kde metapackage is currently broken *anyway*, but I'm not sure yet if leaving it broken and removing a number of other relevant packages to get this transition in is a good trade-off given that the toolchain still needs to be fixed no matter what, and preferably ASAP. Until that decision is made, I'm afraid the rest of this analysis is largely irrelevant. In any case, please see http://ftp-master.debian.org/~vorlon/KDE-missing-bysource.txt for a separate analysis. Incidentally, I count a total of 13 force hints in your email, all of which actually have to be force-hint hints as well (and most of which actually block on gcc-4.0...). As many of these are multi-binary packages, leaving them all in testing in an uninstallable state is not appropriate; and removing them significantly diminishes the usability of the KDE environment in testing, and is also something I'm generally averse to for packages that are themselves not RC-buggy and which aren't going to be able to get back in any time soon. If you want to help move the KDE transition forward, please work on figuring out how to get the toolchain back into shape. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature