Bug 142430 - unnecessary package conflicts with older compat-gcc
Summary: unnecessary package conflicts with older compat-gcc
Alias: None
Product: Fedora
Classification: Fedora
Component: compat-gcc
Version: 3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-12-09 17:59 UTC by Sean Middleditch
Modified: 2007-11-30 22:10 UTC (History)
0 users

Clone Of:
Last Closed: 2004-12-09 21:42:14 UTC

Attachments (Terms of Use)

Description Sean Middleditch 2004-12-09 17:59:10 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020 Epiphany/1.4.4

Description of problem:
The GCC 2.96 compiler was needed on a colleague's machine due to tons
of old code that would not compile on gcc 3.3 or 3.4.

He couldn't get the compat-gcc-7.3-2.96.126 package found online to
install, as it "conflicted" with compat-gcc-8-  The conflict
was entirely bogus - there was no real conflict at all between the two
pieces of software.

However, since both packages were named "compat-gcc", rpm invented its
own little incompatibility.  This was worked around using rpm using
the --oldpackage flag.  However, the colleague was not aware of that
flag, and was considered ditching Fedora for an old version of Red Hat
Linux until I butted in.

This entire problem would not exist if the packaging was done slightly
differently - there was no _real_ software conflict.

I would like to see the compat-gcc packages be renamed in future
releases to compat-gcc-<version> (i.e., compat-gcc-3.3) so that this
kind of conflict can be avoided from now on.  Obviously this can't
retroactively help current releases, but it can improve things down
the road.

On a slightly related note, I'd say that all compat-foo* packages
should explicitly note the version in their package name so that this
sort of artificial software conflict doesn't happen with other
packages in the distribution.  As much as we may wish otherwise,
developers sometimes need ancient libraries and tools, even with open
source software (as in the case of my colleague).

Another suggestion might be to just name all the GCC packages to
gcc-<version> (drop the 'compat' bit), make the gcc package depend on
the latest release, and use the alternatives system to select the

Thank you!

Version-Release number of selected component (if applicable):
compat-gcc-8- compat-gcc-7.3-2.96.126

How reproducible:

Steps to Reproduce:
1. install compat-gcc from FC3 (gcc 3.3)
2. try to install an older compat-gcc to get a completely different
compiler, like gcc-2.96

Actual Results:  Had to manually install the desired package with
--oldpackage.  RPM made it seem like the software was incompatible or
a downgrade, when in fact we were installing a different and
parallel-installable piece of software.

Expected Results:  The desired package, having absolutely no real
install or runtime confliects, should have installed with no
complaints and not requiring manual rpm hackery to install.

Additional info:

The package installed was found on rpmfind.net.  It was the compat-gcc
shipped by an earlier Red Hat release.

Comment 1 Jakub Jelinek 2004-12-09 21:42:14 UTC
Hm, there is conflict between FC3 compat-libstdc++ package and 2.96-RH compat-libstdc++.
Anyway, compat-* packages have been revamped for RHEL4 and will eventually
be changed for FC4 as well (after updating from 3.2.3-RH based one to 3.3.4-RH
based one).

Comment 2 Sean Middleditch 2004-12-09 21:56:26 UTC
Ah.  Is there more information avilable on what exactly those compat-* revamps
are?  I'm running Rawhide and I see the exact same problematic packaging for
compat-* stuff.  I'd like to get a chance to point out any problems with those
changes early on - I figure if you guys are going to fix things up, better make
sure nothing gets overlooked and things get fixed up *right*.  ^_^


Note You need to log in before you can comment on or make changes to this bug.