today's yum dependency issues for rawhide

[Sandro Mani]

On 07/11/2012 11:39 PM, Kevin Martin wrote:
> On 07/11/2012 01:18 PM, Sandro Mani wrote:
>> On Wed, Jul 11, 2012 at 6:59 PM, Kevin Martin <ktmdms at gmail.com> wrote:
>>> On 07/11/2012 11:42 AM, Sandro Mani wrote:
>>>> On Wed, Jul 11, 2012 at 6:36 PM, Bruno Wolff III <bruno at wolff.to> wrote:
>>>>> On Wed, Jul 11, 2012 at 10:12:31 -0500,
>>>>>    Kevin Martin <ktmdms at gmail.com> wrote:
>>>>>> Two questions:
>>>>>>
>>>>>> 1). How do I get rid of the dependency issues shown below?  Do I force the
>>>>>> update of systemd-libs or do the packages that are
>>>>>> dependent on libudev need to be updated?
>>>>>
>>>>> I like to keep the latest versions of rawhide packages installed unless it
>>>>> would require removing something really critical. The way I do a quick check
>>>>> for what is blocking updates is to run:
>>>>> yum update -y -v | grep -i fail
>>>>> Note that sometimes early failures cause later failures so that you really
>>>>> don't need to remove every package listed. There can also be failures that
>>>>> don't show up when doing the above.
>>>>>
>>>>> My fallback plan is to remove the packages that won't update.
>>>>>
>>>>> I track all of the packages I remove and regularly try reinstalling them.
>>>>> --
>>>> Why not just rebuild them in the meantime? I usually simply bump the
>>>> version by one additional "sub-version" (i.e.
>>>> vlc-core-2.0.1-1.fc18.x86_64 -> vlc-core-2.0.1-1.1.fc18.x86_64),
>>>> rebuild with mock, and that's it.
>>>>
>>> The funny thing is that while vlc is *one* of the packages that has libudev dependencies there are a whole bunch more non-rpmfusion
>>> packages that have libudev dependencies as well:
>>>
>> [...]
>> Yeah, but vlc wants libudev.so.0()(64bit), the other ones libudev.so.1()(64bit).
>>
> Please explain why that makes any difference in this discussion.  I'm not sure I see the relevance; vlc want's the 0 version, the
> others want the 1 version, so what?
>
> Kevin
>
The numbers following the .so extension of a shared library denote the 
version. When the binary interface (ABI) to the library changes, the 
number gets "bumped", i.e. increased. ABI changes mean that the 
addresses to symbols change, and consquently all applications using that 
library need to be recompiled, simply to get the new addresses (or to 
discover that a certain symbol does not exist anymore due to API changes).