Confirm

Same.

May be related to https://bugzilla.redhat.com/show_bug.cgi?id=1707712

As a temporary workaround, you can avoid the "skipping packages" noise if you add excludepkgs=liberation-fonts to /etc/yum.repos.d/fedora.repo under the [fedora] section.  This is because the problematic obsoletes is in liberation-fonts-2.00.5-1.fc30, which is only in the fedora repo, while the updates repo has the corrected liberation-fonts-2.00.5-3.fc30.

As noted in bug 1707712, comment 10 this is really a dnf bug.

This is not a problem in DNF, but a packaging issue. Playing with Obsoletes during life time of distribution is dangerous thing. Next time when obsolete is removed it requires version bump over version of obsolete.

Example:
Obsoletes: liberation-narrow-fonts < 1:2.0.0

To overcome the issue it requires release of liberation-narrow-fonts with version 1:2.0.0 or higher.

*** This bug has been marked as a duplicate of bug 1707712 ***

This *is* a DNF problem. It should *not* consider the Obsoletes in liberation-fonts-2.00.5-1.fc30 if the higher EVR liberation-fonts-2.00.5-3.fc30 is available, exactly so that bad Obsoletes can be removed in updates. This is how things worked in YUM and, I believe, even in older versions of DNF, exactly so that this scenario works as expected.

The behavior of YUM was incorrect. YUM always considered only latest packages for transaction, the older packages were completely ignored therefore YUM was unable to handle many situations.
DNF uses libsolv as a solver that consider all possibilities, therefore dnf is capable to resolve transaction that YUM was unable to.


The situation here is based on packaging error that could be resolved by:

1. To overcome the issue it requires release of liberation-narrow-fonts with version 1:2.0.0 or higher.

2. Return the obsolete in liberation-fonts to keep upgrade path.

For dnf this bug has status close with resolution - notabug, therefore changing the component:


In case that maintainers of liberation-narrow-fonts do not agree with solution please change component to liberation-fonts.

In case that maintainers of liberation-fonts do not agree with solution please change component to liberation-narrow-fonts (here I want to mentioned that the issue was originally in liberation-fonts).

Seeing as liberation-narrow-fonts is at version 1.07.5-3, and the previous incorrect obsoletes in liberation-fonts was for 1:2.0.0, the only way to resolve this is to bump the epoch for liberation-narrow-fonts directly to 2.  Does that sound accurate to you Jaroslav?

(In reply to Jaroslav Mracek from comment #6)
> The behavior of YUM was incorrect. YUM always considered only latest
> packages for transaction, the older packages were completely ignored
> therefore YUM was unable to handle many situations.

That behavior complied to user expectations and allowed resolving issues with broken Obsoletes. How would you fix an unwanted entirely unversioned Obsoletes with your approach? There is just no way to fix it then.

You may consider the DNF/libsolv behavior as "correct" under some formal definition, but it does NOT fulfill user expectations, so I consider it wrong. And I am really fed up of unhelpful behavior constantly being dismissed as "not a bug, works by design" (see also bug #1699672, which makes weak dependencies essentially useless).

> DNF uses libsolv as a solver that consider all possibilities, therefore dnf
> is capable to resolve transaction that YUM was unable to.

But DNF is not capable of resolving this transaction that YUM would have been able to. At least not without falsely complaining about "broken" dependencies, which are not broken.

> The situation here is based on packaging error that could be resolved by:
> 
> 1. To overcome the issue it requires release of liberation-narrow-fonts with
> version 1:2.0.0 or higher.
> 
> 2. Return the obsolete in liberation-fonts to keep upgrade path.

2 would be completely wrong behavior. liberation-fonts does NOT replace liberation-narrow-fonts, and liberation-narrow-fonts is specifically packaged as a separate package to provide that font. And at least WINE actually wants that font, it seems (which is why people are now seeing the "broken" dependencies without explicitly having installed liberation-narrow-fonts).

1 is doable, but very ugly, and it would not be possible if the Obsoletes had been entirely unversioned.

I insist: a solution in DNF is needed.

The point is, the Obsoletes in liberation-fonts in @fedora was completely bogus and there ought to be a safe way to withdraw it in an update. With DNF's current behavior, we are stuck.

Note updates for liberation-narrow-fonts have been pushed to testing.

Feel free to move this to dnf (etc) if you wish or open a new RFE.

(In reply to Jaroslav Mracek from comment #6)
> The behavior of YUM was incorrect. YUM always considered only latest
> packages for transaction, the older packages were completely ignored
> therefore YUM was unable to handle many situations.
> DNF uses libsolv as a solver that consider all possibilities, therefore dnf
> is capable to resolve transaction that YUM was unable to.

After reading this, I still don't understand *why* dnf takes into account
the Obsoletes from a removed package. If instead of Obsoletes, the old removed
package had Provides:foo, and an installed package had Requires:foo, dnf would
consider this an unsatisfied dependency. Similarly, if we have foo-1.0, and
bar-1.0 with Requires foo=1.0, and we upgrade to foo-1.1 and bar-1.1 with
Requires foo=1.1, this is OK. We go from one consistent state to another
consistent state.

This bug is already fixed in liberation-fonts-2.00.5-6.fc31. 
Hence closing this bug, feel free to reopen if the problem persists.