fedup f20->f21 kde broken deps

[Michael Schwendt]

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.