Bug 1814543 - Incomplete information provided, blocking dnf update
Summary: Incomplete information provided, blocking dnf update
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-obsolete-packages
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miro Hrončok
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-03-18 07:50 UTC by Milan Crha
Modified: 2020-03-27 07:59 UTC (History)
2 users (show)

Fixed In Version: fedora-obsolete-packages-32-43
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-27 07:59:56 UTC
Type: Bug


Attachments (Terms of Use)

Description Milan Crha 2020-03-18 07:50:44 UTC
I just tried to call dnf update in my rawhide machine and this came out of it:

--------------------------------------------------------------------------
# dnf update --refresh
Fedora 33 openh264 (From Cisco) - x86_64        180  B/s | 543  B     00:03    
Fedora - Modular Rawhide - Developmental packag  10 kB/s |  14 kB     00:01    
Fedora - Modular Rawhide - Developmental packag 200 kB/s | 160 kB     00:00    
Fedora - Rawhide - Developmental packages for t  18 kB/s |  14 kB     00:00    
Fedora - Rawhide - Developmental packages for t 530 kB/s | 1.7 MB     00:03    
Dependencies resolved.

 Problem: package fedora-obsolete-packages-33-6.noarch obsoletes python2-backports-functools_lru_cache < 1.5-7 provided by python2-backports-functools_lru_cache-1.5-6.fc31.noarch
  - package python2-soupsieve-1.9.2-2.fc32.noarch requires python2.7dist(backports.functools-lru-cache), but none of the providers can be installed
  - package python2-soupsieve-1.9.2-2.fc32.noarch requires python2dist(backports.functools-lru-cache), but none of the providers can be installed
  - cannot install the best update candidate for package exaile-4.0.0-3.fc31.noarch
  - problem with installed package python2-soupsieve-1.9.2-2.fc32.noarch
Nothing to do.
Complete!

--------------------------------------------------------------------------

I'd say that the fedora-obsolete-packages package update should not break update path. But maybe I'm wrong. Using `dnf update --allowerasing --best` works [1], even it's not suggested by dnf (it is sometimes suggested to use either of the options, or it used to be in the past).


[1] From dnf:

Installing dependencies:
 python3-mutagen                        noarch  1.43.0-2.fc32   rawhide   357 k
     replacing  python2-mutagen.noarch 1.42.0-7.fc32
Removing dependent packages:
 exaile                                 noarch  4.0.0-3.fc31    @rawhide  7.5 M
 python2-backports                      x86_64  1.0-17.fc31     @rawhide  638  
 python2-backports-functools_lru_cache  noarch  1.5-6.fc31      @rawhide   17 k
 python2-beautifulsoup4                 noarch  4.8.0-2.fc32    @rawhide  917 k
 python2-cddb                           x86_64  1.4-26.fc31     @rawhide   59 k
 python2-gobject                        x86_64  3.34.0-3.fc32   @rawhide   24 k
 python2-gobject-base                   x86_64  3.34.0-3.fc32   @rawhide  1.3 M
 python2-gstreamer1                     x86_64  1.16.1-1.fc32   @rawhide  436 k
 python2-soupsieve                      noarch  1.9.2-2.fc32    @rawhide  242 k

Transaction Summary
================================================================================
Install  1 Package
Remove   9 Packages


Interestingly, it doesn't mention fedora-obsolete-packages at all.

Comment 1 Miro Hrončok 2020-03-18 10:07:25 UTC
So the idea is that fedora-obsolete-packages obsoletes packages that would otherwise block the break update path.
However, if not all of such packages are obsoleted, it looks like it's fedora-obsolete-packages that breaks it.

To fix this, it must obsolete all of the following removed packages:

 exaile                                 noarch  4.0.0-3.fc31    @rawhide  7.5 M
 python2-backports                      x86_64  1.0-17.fc31     @rawhide  638  
 python2-backports-functools_lru_cache  noarch  1.5-6.fc31      @rawhide   17 k
 python2-beautifulsoup4                 noarch  4.8.0-2.fc32    @rawhide  917 k
 python2-cddb                           x86_64  1.4-26.fc31     @rawhide   59 k
 python2-gobject                        x86_64  3.34.0-3.fc32   @rawhide   24 k
 python2-gobject-base                   x86_64  3.34.0-3.fc32   @rawhide  1.3 M
 python2-gstreamer1                     x86_64  1.16.1-1.fc32   @rawhide  436 k
 python2-soupsieve                      noarch  1.9.2-2.fc32    @rawhide  242 k

Yet it doesn't, it only obsoletes:

exaile < 4.0.0-4
python2-backports < 1.0-18
python2-backports-functools_lru_cache < 1.5-7
python2-beautifulsoup4 < 4.8.1-2
python2-cddb < 1.4-27
python2-gobject < 3.34.0-4
python2-gobject-base < 3.34.0-4
python2-gstreamer1 < 1.16.2-2
python2-soupsieve < 1.9.2-2

I see that python2-soupsieve has a bad version obsoleted and that the bug.


> Interestingly, it doesn't mention fedora-obsolete-packages at all.

Yes, because it removes python2-soupsieve and so there is no more problem.


I'll fix this in rawhide and Fedora 32.

Comment 2 Milan Crha 2020-03-18 10:22:42 UTC
(In reply to Miro Hrončok from comment #1)
> > Interestingly, it doesn't mention fedora-obsolete-packages at all.
> 
> Yes, because it removes python2-soupsieve and so there is no more problem.

Not really 'yes' from my point of view, but I do not know how this is supposed to work in reality. What I expect is that when I install a package, its provides/obsoletes/requires are all taken into consideration and necessary steps are taken immediately, which didn't happen here. If I understand my situation correctly, then the fedora-obsolete-packages had been updated in some previous 'dnf update' call, and only the next 'dnf update' call begun to obsolete already installed packages. I'm pretty sure these had been installed when fedora-obsolete-packages had been installed/updated, I do not install python packages on my own usually. That's the reason why I'd expect seeing fedora-obsolete-packages mentioned in the list of to-be-done changes in the [1] from the comment #0.

Comment 3 Miro Hrončok 2020-03-18 10:26:31 UTC
Note that fedora-obsolete-packages self removes itself after the transaction, so if there is no problem, you don't see it listed at all.

Comment 4 Milan Crha 2020-03-18 11:03:39 UTC
(In reply to Miro Hrončok from comment #3)
> Note that fedora-obsolete-packages self removes itself after the
> transaction, so if there is no problem, you don't see it listed at all.

Interesting. I hope it's not downloaded every time I run 'dnf update', that would feel like a waste of bandwidth.

Comment 5 Miro Hrončok 2020-03-18 11:22:52 UTC
Honestly, I don't really know if it is downloaded at all. There are two scenarios I can think of:


1) It's only downloaded if you have packages installed that are obsoleted by f-o-p. It obsoletes them and goes away.
2) Like the above but since only the metadata are needed, the actual RPM package is never downloaded.


I think the second point is more plausible, but I have not studied the libsolv/dnf code.

Comment 6 Milan Crha 2020-03-18 11:26:49 UTC
Okay, that's fine. The most surprising thing, to me, is that it doesn't behave like a regular package (not installed packages do not influence the installation). Everything else is just an implementation detail.

Comment 7 Fedora Update System 2020-03-19 02:26:07 UTC
fedora-obsolete-packages-32-43 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4665f9ec2b

Comment 8 Fedora Update System 2020-03-27 07:59:56 UTC
FEDORA-2020-4665f9ec2b has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.