On Fri, Nov 09, 2001 at 12:00:21PM -0500, Phil Edwards wrote: > There's probably an easy way out of this mess, but I'm somewhat new > to Debian. (Been using Linux for years, but just recently switched to > using a distro rather than hacking everything together by hand.) > > For a while now I've had both gcc/gcc-2.95 and gcc-3.0 installed; three > packages in all. I briefly tried uninstalling the gcc/gcc-2.95 packages > (why are there two of them? they're the same thing, aren't they?) but > found that the gcc-3.0 package doesn't use the "alternatives" links to > provide /usr/bin/gcc, etc.
The Debian gcc packages are organized as follows: * gcc-$(version) packages exist for various architectures, depending on where they work. * The gcc-defaults source package generates the 'gcc' binary package, which depends on the "best" gcc-$(version) for each architecture. * If you want to use the alternative compilers, use /usr/bin/gcc-3.0 (or set CC=gcc-3.0, or whatever). This is essentially to avoid the hideous problems that might occur if, say, a maintainer had used 'update-alternatives --config gcc' to switch to gcc-3.0, and then built and uploaded a C++-based library with that. > The update_alternatives(8) man page doesn't list any examples of how to > use it, and I didn't feel like single-handedly destroying my system finding > out while experimenting. :-) Heh. The --install and --remove options are really only meant for use by packages. > So, back to gcc and gcc-2.95. > > But now dselect is constantly signalling conflicts: > > gcc conflicts with gcc-doc (<< 2.95.3) > gcc-2.95 depends on gcc (>= 2.95.3-2) > kernel-source-2.2.19 recommends gcc > kernel-package recommends gcc > > And dselect's recommended solution is to uninstall gcc, uninstall gcc-2.95, > uninstall the kernel source, the kernel package, all of KDE and all of > Python -- just so that it can install gcc-doc instead. > > "task-devel-common" is what's demanding that gcc-doc be installed. Both gcc-doc and task-devel-common are obsolete. gcc-doc still exists in testing, although I'm not quite sure why the testing bot hasn't decided to remove it yet; it's been replaced by gcc-$(version)-doc. task-devel-common has been removed from both testing and unstable, as the task packages have been replaced by a mechanism that stands a chance of causing the freeze fewer problems this time round. Your best bet is to try to get task-devel-common uninstalled. I'm kind of surprised that dselect complained about that, as nothing in testing/i386 currently depends on it. I assume you're using testing? Which architecture? > (Ironically, the reason I want to get rid of gcc-2.95 entirely and use > only gcc-3.x is that I'm a GCC maintainer, and want to do lots of testing > with the 3.x series. If the solution to this dependancy mess involves > destroying gcc-doc, that's fine with me; I have many copies of the GCC > manual already. :-) You could build your own gcc-defaults package, if you like, that depends on gcc-3.0 rather than gcc-2.95. That shouldn't be too difficult. Cheers, -- Colin Watson [EMAIL PROTECTED]