On Thu, 1 Dec 2016 17:03:30 -0500
Przemek Klosowski <przemek.klosowski(a)nist.gov> 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.