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. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
