On Sat, Dec 13, 2014 at 11:48 AM, Michael Schwendt <mschwendt@xxxxxxxxx> 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 ;) -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
