Re: GCC packages fighting amongst themselves?
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 [cjwatson@flatline.org.uk]
Reply to: