fedup f20->f21 kde broken deps

[drago01]

On Sat, Dec 13, 2014 at 11:48 AM, Michael Schwendt <mschwendt at gmail.com> wrote:
> On Fri, 12 Dec 2014 12:16:34 -0800, Adam Williamson wrote:
>
>> Awesome, so now you have me running a test install of F20 with R just
>> to see what happens in this situation. There's certainly no other way I
>> could be using my damn morning.
>
> Well, the problems are real. Unresolvable deps in many cases are equal to
> denial-of-service at runtime, i.e. the programs don't execute.
>
> In some cases and depending on whether the system survives the reboot, a
> distro-sync may work. Doing downgrades of packages bears even further
> risks, though (and in most cases are completely untested). [For example,
> there are cases where parts of the software and/or packages have converted
> settings and other runtime files already only to run into breakage later
> on, such as a broken component.]
>
> Btw, this morning I've had fun porting Audacious plugins to the new API.
>
>> We seem to keep going in circles here.
>
> I hear you well. Going in circles cannot be avoided. My opinion in this
> matter is: If individual package maintainers are not careful enough to
> violate upgrade paths, update release procedures ought to get adjusted.
>
> It may be that you're happy (so far) with suggesting a distro-sync as a
> preliminary work-around. Users are scared by such extra commands, however,
> especially if Yum asks for confirmation before wanting to remove (!) and
> downgrade packages.
>
> Violated upgrade paths are an issue all the time. Not only shortly before
> release of next Fedora! There's always some sort of window when packagers
> mass-release upgrades to multiple dists and cause an upgrade race. Sometimes
> just a few days, sometimes a week, sometimes several weeks, if a test update
> is forgotten or withdrawn.  Shortly before a new release of Fedora it can
> be worse, however, because users are not interested in Test Releases that
> are not "ready".  They hope for the final release to just work. Meanwhile
> they continue the drill and apply updates daily, and if they happen to
> hear about the new Fedora release, they upgrade from an up-to-date earlier
> release where packages are even newer than in the release they upgrade
> to. If the upgrade method cannot handle that, yes, repeating that won't
> improve it. Facing the facts is necessary, though.
>
>> work, I think it's taking things too far to say that it's worthless to
>> test upgrades against updates-testing, which was one place where we
>> started this endless debate.
>
> We two have not been the only participants in this thread.
>
> *I* haven't claimed that test upgrades to updates-testing are worthless.
>
> But I claim that the ordinary user doesn't upgrade to updates-testing and
> doesn't want to upgrade to updates-testing due to some of the stuff that's
> dumped in there. Too many updates, too many packages updated too frequently.
>
> Hey, perhaps even a name change would make that repo less intimidating:
> "update-candidates". ;)  A bit of an obfuscation contest, unfortunately,
> and much too lose if such a repo causes severe breakage.  Plain users don't
> want to be the guinea pigs to install Test Updates, which may be entirely
> _untested_. They want the Fedora Project to ensure the quality of
> updates. And quality ensurance needs to start somewhere.  We can't dump
> random upgrades into updates-testing and only hope that withdrawing them
> may be enough. Burnt repo users may be fed up when that happens regularly.
>
>> * The obvious way you can really 'solve' this 'problem' is to tighten
>> down the updates policy, but that's not a free action. It *does* come
>> with negative consequences and there *will* be pushback against it
>> from packagers.
>
> Of course.
>
>> Personally I am totally happy if anyone wants to come
>> up with a comprehensive proposal for adjusting the updates policy and
>> *take it to FESCo*, who own the updates policy. If someone comes up
>> with such a proposal, we can even put it up for discussion on this
>> list or in a QA meeting and decide if QA as a whole wants to back it
>> in the FESCo discussion.
>
> That doesn't work for me.  It doesn't work for me at all, if people hide
> somewhere, are not interested in the topic on this list, and would not be
> informed at all when learning about the topic in a meeting.
>
>> But I'm just tired of going around in endless
>> discussion, especially when no-one seems to acknowledge the issue just
>> isn't as straightforward as 'oh well it's OBVIOUSLY wrong and we
>> should OBVIOUSLY just have strict upgradepath enforcement'.
>
> Well, early resistance kills all progress. Early.
>
> Some of this discussion is ridiculous. On one hand, delaying upgrades for
> old dist releases is considered a major problem, because those upgrades
> may be oh-so-important-brown-paperbag-showstopper-fixes. On the other hand,
> for the latest dist release a distro-sync downgrade is suggested, which
> downgrades to old packages where the oh-so-important upgrade is not
> available yet or only in updates-testing. Something's wrong here with
> the release process. It may be the first dist upgrade for some Fedora
> users!
>
>> The other path you can take is to try and convince wwoods to have
>> fedup do distro-sync. The bug reports for that are
>> https://bugzilla.redhat.com/show_bug.cgi?id=892061 and h
>> ttps://github.com/wgwoods/fedup/issues/21 . Given that wwoods filed
>> https://github.com/wgwoods/fedup/issues/21 himself, I'm guessing he'd
>> welcome a patch.
>
> I would welcome Fedora leadership to address all packagers and raise
> awareness of the problem.

So how about:

1) Add epoch: N to all FN packages
2) Ignore people complaining about epoch being ugly
3) FN+1 > FN is always the case because of 1
4) Profit

;)