bohdi AutoQA: depcheck test FAILED

[Alec Leamas]

On 08/21/2012 04:22 PM, Kamil Paral wrote:
>> hi,
>> i need help, because the AutoQA DepCheck fails on the package
>> speed-dreams,but the package was pushed anyway.
>> AutoQA DepCheck log:
>> http://autoqa.fedoraproject.org/results/418027-autotest/virt04.qa/depcheck/results/speed-dreams-2.1.0-1.html
>>
>> the problem was already discussed on
>> http://forums.fedoraforum.org/showthread.php?t=283254&page=2
> Depcheck fails, because your x86_64 package requires a dependency that is not available:
>
> $ yum provides 'libenet-1.3.3.so'
> Loaded plugins: changelog, langpacks, refresh-packagekit, remove-with-leaves, show-leaves
> No Matches found
>
> The package has been pushed just to updates-testing [1]. Please make sure it is not pushed to stable updates. Unpush it, fix the dependency problem, and then push it to Bodhi again.
>
Yes, the package is broken and must not end up in stable, agreed.

The next question is why. Looking at my own f-17 box, it's obvious that 
the current state of enet is libenet-1.2.1. This is the same version as 
in f16.The specfile is not conditionalized in any way. Still, the f16 
build Requires: 1.2.1 whereas the f17 wants 1.3.3.

Which brings the question: how can the same spec could end up in a build 
requiring libenet-1.3.3 (in f17) or libenet1.2.1 (in f16), even though 
the correct version in both cases seems to be libenet-1.2.1? How could 
anything built on F17 require a non-existing version, using automatic 
dependencies?

I really wish I could understand this, thus becoming a Real Wizard - or, 
possibly, just not a ...... (place for proper noun)

--alec