On Thu, 1 Dec 2016 17:03:30 -0500 Przemek Klosowski <przemek.klosowski@xxxxxxxx> wrote: > On 12/01/2016 04:39 PM, Howard Howell wrote: > > It looks like probably Dominik's suggestion of the -e cleared the > > program. So somehow, rpm -e packagename seemed to be the magic > > bullet. I will start overwith the update to make sure all the > > packages downloaded, and let you know if success happens. > FWIW, I had several file conflicts resulting from standard F24 > packages that blocked the upgrade to F25. > > https://bugzilla.redhat.com/show_bug.cgi?id=1396848 > > https://bugzilla.redhat.com/show_bug.cgi?id=1396849 > > https://bugzilla.redhat.com/show_bug.cgi?id=1396319 > > that required dnf erase <offendingpackage>. Sometimes these > erasures had a slightly worrying amount of dependencies (a dozen, not > hundreds, though), and in each case they reinstalled smoothly after > the OS upgrade. Two of those have been promptly fixed by the > packagers, and apparently are no longer an isssue. > > This got me thinking if there's a common root cause that could be > checked automatically? I didn't quite understand what exactly > happened in the affected packages to cause it. > Usually this is because of library version conflicts. The F24 package was compiled with an earlier library, but your upgrade is going to replace that library with a new version, and there is no F25 package (yet) that uses the new library version. =><= I think this is due to the freeze, as packages accumulate in updates and updates testing during the freeze before release. That's why they updated so smoothly after the upgrade. There was a discussion on this list recently about this very issue, and my take away from that discussion was that this is a consequence of the release process itself, and would be non-trivial to fix. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
