fedup f20->f21 kde broken deps

[Ralf Corsepius]

On 12/04/2014 06:43 AM, Adam Williamson wrote:
> On Thu, 2014-12-04 at 06:16 +0100, Ralf Corsepius wrote:
>
>> Untrue. All you need to do is to apply the "after release" update policy.
>
>> I.e.: push updates to "updates" on both Fedora(N) and Fedora(N+1). When
>> you need to cut a snapshot, move Fedora(N+1) updates into the main
>> repository.
>
> Hum. It might be possible to use the branched updates during freezes in
> that way, yeah. Have to see what releng thinks.
>
>>> 2. Implement a perfect and strictly-enforced upgradepath test and
>>> abandon milestone freezes
>>>
>>> The consequence of this would be be we'd probably never manage to get
>>> the damn milestone releases done because people would keep pushing
>>> changes that break them.
>>>
>>> Neither of those seems likes an improvement on the current situation to
>>> me.
>> Well, right now, you can't test upgrading and are likely to be broken
>> upgrade paths (as Fedora had always done).
>
> You can test fine; just test with updates-testing.
No.

"updates-testing"'s purpose is to test update-candidate "packages". I.e. 
these packages may never end up in "updates" for a variety of reasons.

"updates" purpose is to provide updates to packages in "release".
i.e. they must integrate perfectly into release.

The difference is important in release preparation stages of a Fedora 
release.

> Just for the purpose of testing upgrade.img, you can simply enable
> updates-testing if it turns out you have a situation like this and you
> need a package from u-t to make the upgrade package set viable.
This is not true. They are completely different scenarios.

The purpose of using "release"+"updates"+"updates-testing" is entirely 
different from using "release"+"updates", esp. in stages like these.

The purpose of using "release"+"updates" is to test upgrading to 
Fedora(N+1) (and testing fedup/yum/dnf-support ) and not to test 
update-candidate packages from "update-testing".

Ralf