Troy Dawson wrote:
Jeffrey D Anderson wrote:
I have a machine pointing to the SL4x rolling repository that just got updated
to SL46.
I have the following repos enabled:
epel
sl-errata
sl-base
Today I tried to install httpd-devel and got this:
[EMAIL PROTECTED] yum.repos.d]# yum install httpd-devel
Loading "kernel-module" plugin
Setting up Install Process
Setting up repositories
Reading repository metadata in from local files
Parsing package install arguments
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package httpd-devel.i386 0:2.0.52-38.sl4.2 set to be updated
--> Running transaction check
--> Processing Dependency: apr-util-devel for package: httpd-devel
--> Processing Dependency: apr-devel for package: httpd-devel
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package apr-devel.i386 0:0.9.4-24.9 set to be updated
---> Package apr-util-devel.i386 0:0.9.4-22.el4 set to be updated
--> Running transaction check
--> Processing Dependency: gcc = 3.4.5 for package: apr-devel
--> Finished Dependency Resolution
Beginning Kernel Module Plugin
Finished Kernel Module Plugin
Error: Missing Dependency: gcc = 3.4.5 is needed by package apr-devel
It looks like apr-devel needs to be rebuilt for the new SL46 release.
That's bizarre.
Thanks for pointing that out. I'm not quite sure how that happened, but we'll
get it fixed.
Troy
*grumble grumble grumble*
Looks like this has always been broken and nobody has noticed.
For some reason in this one rpm they check and see what version of gcc it is
being compiled with and say that is what it depends on.
All other rpm's either just say gcc or libgcc_s.so.1 or something more generic.
As far as I can tell, there is nothing specific about this rpm that requires
the version of gcc it was compiled with, it's just a poorly written rpm spec
file. (In my opnion)
I know that doesn't fix the bug yet ... I'm just grumbling, because I really
*hate* having to change rpm's for no other reason that the spec file was poorly
written. And I haven't figured out a way to push this back to the vendor,
because it fit's with their building/releasing scheme.
Troy
--
__________________________________________________
Troy Dawson [EMAIL PROTECTED] (630)840-6468
Fermilab ComputingDivision/LCSI/CSI DSS Group
__________________________________________________
