[ATrpms-users] curl binary?

[Chris Schanzle]

On 01/17/2011 03:30 AM, Axel Thimm wrote:
> On Sun, 2011-01-16 at 21:18 -0500, Chris Schanzle wrote:
>    
>> On 01/14/2011 12:00 PM, Noel Leistad - atrpms wrote:
>>      
>>> Platform EL5 (CentOS)
>>>
>>> w/ atrpms-testing repo enabled,
>>>
>>> attempts to install curl reports curl obsoleted by libcurl3, however,
>>> libcurl3, at least as reported on my system only installs 2 .so files,
>>> not the binary???
>>>
>>> Source of binary that doesn't conflict w/ the libcurl3 package?
>>>        
> The binary is also in atrpms-testing. BTW this is the official vendor
> upgrade scheme within RHEL (5->6).
>
> I wonder why yum upgrade didn't catch the binary as well. Maybe a bug in
> yum? Or do you have any selective/partial filtering turned on?
>
>    
>> Confirming the same observation here too.  Requiring the main curl
>> package (same version) seems to help:
>>      
> The split was made so that one can install libcurl w/o the binary, so
> adding this dependency effectively molds the subpackages back to one
> again.
>    

Axel,

I see what you were trying to do, but since you're *replacing* curl with 
libcurl3, and libcurl3 doesn't include a binary, existing CentOS 
installs don't get curl updated, so no curl binary is left on the 
system.  For the EL5 systems, I'd prefer to maintain parity with the 
existing package structure, or come up with a different way to not break 
things.

If we link libcurl3 and curl back together for el5, what's the harm?  
They were together in the original centos packages.  Surely that's 
better than leaving users with no curl command.

Maybe the better solution would have your newer curl package depend on 
libcurl3, even if it didn't, and remove the Obsoletes?  I am far less 
experienced than you in these subtle effects of packaging.


Below you can see the problem.  I use 'protect=yes' on my centos repo's; 
especially now that I must enable atrpms-testing for some atrpms 
packages, I want to limit the amount of atrpms changes.  But I think it 
makes no difference in this case.  Here's what I get after disabling 
protect=yes on the centos repos - (I have newer curl packages in my 
'mcsd' repo, which is why I disabled that repo below):


# rpm -q curl              # - these are the CentOS packages
curl-7.15.5-9.el5.i386
curl-7.15.5-9.el5.x86_64


# yum --disablerepo=mcsd\*  update curl
Loaded plugins: aliases, allowdowngrade, changelog, downloadonly, 
fastestmirror,
               : filter-data, kernel-module, keys, kmdl, kmod, list-data,
               : priorities, protect-packages, protectbase, security, 
tmprepo,
               : tsflags, upgrade-helper, verify, versionlock
Loading mirror speeds from cached hostfile
  * addons: darkstar
  * atrpms: darkstar
  * atrpms-testing: darkstar
  * base: darkstar
  * epel: darkstar
  * extras: darkstar
  * updates: darkstar
Reducing Extra Packages for Enterprise Linux 5 - x86_64 to included 
packages only
Finished
Skipping filters plugin, no data
4 packages excluded due to repository priority protections
0 packages excluded due to repository protections
Skipping security plugin, no data
Reading version lock configuration
Setting up Update Process
Resolving Dependencies
Skipping filters plugin, no data

Skipping security plugin, no data
--> Running transaction check
---> Package libcurl3.x86_64 0:7.15.5-9_1.el5 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
  Package        Arch         Version                 
Repository            Size
================================================================================
Installing:
  libcurl3       x86_64       7.15.5-9_1.el5          
atrpms-testing       126 k
      replacing  curl.x86_64 7.15.5-9.el5


Transaction Summary
================================================================================
Install       1 Package(s)
Upgrade       0 Package(s)

Total download size: 126 k
Is this ok [y/N]: Exiting on user Command