fedup f20->f21 kde broken deps

[Neal Becker]

Samuel Sieb wrote:

> On 12/03/2014 07:38 AM, Michael Schwendt wrote:
>> On Wed, 03 Dec 2014 08:07:10 -0500, Neal Becker wrote:
>>
>>> fedup gave me the following warnings:
>>>
>>>     kde-runtime-libs-4.14.3-2.fc20.x86_64 requires exiv2-
>>> libs-0.23-5.fc20.x86_64,
>>> OpenEXR-libs-1.7.1-6.fc20.x86_64, libgcrypt-1.5.3-2.fc20.x86_64,
>>> ilmbase-1.0.3-7.fc20.x86_64, libwebp-0.3.1-3.fc20.x86_64
>>
>> Well, I have yet to hear good things about fedup, so take the following
>> with a grain of salt.
>>
> Well then here's one.  Fedup works great!  I've used it many times with
> no problems.
> 
>> # yum list kde-runtime-libs
>> Loaded plugins: langpacks
>> Available Packages
>> kde-runtime-libs.i686                4.14.3-2.fc21              
>> updates-testing
>> kde-runtime-libs.x86_64              4.14.3-2.fc21              
>> updates-testing
>>
>> This only shows that a "higher" kde-runtime-libs package is available for
>> F21, albeit only in the updates-testing repo. Does fedup upgrade to
>> updates-testing or just F21 Beta release +/- updates repo?
>>
> Fedup uses the repo configuration from your current Fedora install.  If
> you don't have updates-testing enabled, then use:
> fedup --network 21 --product=whatever --enablerepo=updates-testing
> 
>> In case it does not, this is typical upgrade path breakage that has
>> plagued Fedora for a long time already. You would strictly need to
>> upgrade _to_ F21 updates-testing to avoid this.
>>
>> Upgrading from an up-to-date F(n-1) to F(n) only works well, if every
>> package in F(n) is "higher" than F(n-1). That assumption breaks easily, if
>> somebody has installed latest updates for F(n-1) [possibly even including
>> test updates] but upgrades to something "older", such as a release without
>> updates and/or updates-testing.
>>
> Yes, the issue of the upgrade path breaking around release time is a
> very tricky problem to solve.  Either use updates-testing or ignore the
> breakage (if it's not critical).  When the release happens, the updates
> will be released and the packages will be generally available.
> 

I don't want to use updates-testing indiscriminatly, because there's no telling 
what that will drag in.

What is needed here, is an option to yum to use updates-testing _only_ to solve 
broken deps.

-- 
-- Those who don't understand recursion are doomed to repeat it