Bug 1457336 - files from python-libs-2.7.13-2.fc25.x86_64 conflict with files from python2-libs-2.7.13-8.fc26.x86_64
Summary: files from python-libs-2.7.13-2.fc25.x86_64 conflict with files from python2-...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: python
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Miro Hrončok
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Keywords:
Depends On:
Blocks: F26BetaBlocker F26BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2017-05-31 14:17 UTC by Kamil Páral
Modified: 2017-06-09 19:20 UTC (History)
14 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2017-06-09 19:20:37 UTC


Attachments (Terms of Use)

Description Kamil Páral 2017-05-31 14:17:44 UTC
Description of problem:
I'm trying to upgrade fully updated F25 Workstation to F26. Whether using dnf system-upgrade or gnome-software, the upgrade fails during transaction check with these errors:

Error: Transaction check error:
  file /usr/lib64/python2.7/bsddb/__init__.pyc from install of python2-libs-2.7.13-8.fc26.x86_64 conflicts with file from package python-libs-2.7.13-2.fc25.x86_64
  file /usr/lib64/python2.7/compiler/__init__.pyc from install of python2-libs-2.7.13-8.fc26.x86_64 conflicts with file from package python-libs-2.7.13-2.fc25.x86_64
  file /usr/lib64/python2.7/ctypes/__init__.pyc from install of python2-libs-2.7.13-8.fc26.x86_64 conflicts with file from package python-libs-2.7.13-2.fc25.x86_64
  file /usr/lib64/python2.7/ctypes/macholib/__init__.pyc from install of python2-libs-2.7.13-8.fc26.x86_64 conflicts with file from package python-libs-2.7.13-2.fc25.x86_64
...
<etc, for all files inside python-libs>

It seems that python-libs package is not properly obsoleted.


Version-Release number of selected component (if applicable):
python-libs-2.7.13-2.fc25.x86_64
python2-libs-2.7.13-8.fc26.x86_64

How reproducible:
always

Steps to Reproduce:
1. install F25 Workstation, fully update
2. follow https://fedoraproject.org/wiki/DNF_system_upgrade and try to upgrade to F26

Comment 1 Kamil Páral 2017-05-31 14:19:51 UTC
Proposing as F26 Beta 0-Day Blocker:
"For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that package set installed. "
https://fedoraproject.org/wiki/Fedora_26_Beta_Release_Criteria#Upgrade_requirements

Comment 2 Charalampos Stratakis 2017-05-31 14:27:15 UTC
That shouldn't happen, and I think I actually tested the upgrade path before.

Will retest it.

Comment 3 Miro Hrončok 2017-05-31 14:50:24 UTC
Actually I haven't noticed before, but this is my Fedora 26 machine after upgrading from Fedora 25:

$ rpm -qa | grep python | grep fc25 
python-2.7.13-2.fc25.x86_64
micropython-1.8-1.fc25.x86_64
python-tools-2.7.13-2.fc25.x86_64
python-libs-2.7.13-2.fc25.x86_64
python-devel-2.7.13-2.fc25.x86_64

Comment 4 Miro Hrončok 2017-05-31 14:55:09 UTC
Could this be a dnf problem?


$ rpm -qp --obsoletes Downloads/python2-2.7.13-8.fc26.x86_64.rpm 
python < 2.7.13-2

[~]$ dnf repoquery --obsoletes python2-2.7.13-8.fc26.x86_64
python2-0:2.7.13-8.fc26.x86_64

Comment 5 Miro Hrončok 2017-05-31 14:58:11 UTC
From a Fedora 25 mock:

# dnf repoquery --obsoletes python2-2.7.13-8.fc26.x86_64 --releasever 26
python < 2.7.13-2

Comment 6 Miro Hrončok 2017-05-31 15:02:23 UTC
Nevertheless I think the problem is it obsoletes "python < 2.7.13-2" while the thing in Fedora 25 is not < 2.7.13-2. Regardless of the guidelines, I think it should obsolete "python <= %{version}-%{release}" to fix this problem.

Comment 7 Miro Hrončok 2017-05-31 15:05:58 UTC
(In reply to Miro Hrončok from comment #4)
> Could this be a dnf problem?
> 
> 
> $ rpm -qp --obsoletes Downloads/python2-2.7.13-8.fc26.x86_64.rpm 
> python < 2.7.13-2
> 
> [~]$ dnf repoquery --obsoletes python2-2.7.13-8.fc26.x86_64
> python2-0:2.7.13-8.fc26.x86_64

Reported at bz1457368

Comment 8 Miro Hrončok 2017-05-31 15:07:32 UTC
(In reply to Charalampos Stratakis from comment #2)
> That shouldn't happen, and I think I actually tested the upgrade path before.

You've tested it when there was 2.7.13-1 in Fedora 25.

Comment 9 Kamil Páral 2017-05-31 15:13:40 UTC
> 1. install F25 Workstation, fully update

I was wrong here, python-libs is not a part of a default Workstation installation. Not part of a default Server installation either, but it's on F25 Server DVD, so when I checked all the addons in anaconda, it got installed.

However, when I try to upgrade the package from the Server, I don't see a transaction failure. python-libs is not even mentioned in the upgrade log, and python2-libs rpm is not download. After upgrade, python-libs-2.7.13-2.fc25.x86_64 is still installed and not upgraded.

I'm not clear why it behaves differently from what I initially saw on Workstation.

Comment 10 Miro Hrončok 2017-05-31 15:15:38 UTC
Fix ready, testing in mock.

Comment 11 Miro Hrončok 2017-05-31 15:16:45 UTC
(In reply to Kamil Páral from comment #9)
> > 1. install F25 Workstation, fully update
> 
> I was wrong here, python-libs is not a part of a default Workstation
> installation. Not part of a default Server installation either, but it's on
> F25 Server DVD, so when I checked all the addons in anaconda, it got
> installed.
> 
> However, when I try to upgrade the package from the Server, I don't see a
> transaction failure. python-libs is not even mentioned in the upgrade log,
> and python2-libs rpm is not download. After upgrade,
> python-libs-2.7.13-2.fc25.x86_64 is still installed and not upgraded.
> 
> I'm not clear why it behaves differently from what I initially saw on
> Workstation.

That is consistent with my machine. Later when you try to dnf install python2, it will fail with the file conflicts.

Comment 12 Miro Hrončok 2017-05-31 18:45:17 UTC
Rawhide https://koji.fedoraproject.org/koji/taskinfo?taskID=19794348
F26 https://koji.fedoraproject.org/koji/taskinfo?taskID=19794945

Waiting for slow arches, but x86_46 works for me:

$ LANG=C.utf8 dnf install python2*2.7.13-10.fc26*rpm
Dependencies resolved.
================================================================================
 Package              Arch        Version               Repository         Size
================================================================================
Installing:
 python2              x86_64      2.7.13-10.fc26        @commandline       97 k
     replacing  python.x86_64 2.7.13-2.fc25
 python2-devel        x86_64      2.7.13-10.fc26        @commandline      408 k
     replacing  python-devel.x86_64 2.7.13-2.fc25
 python2-libs         x86_64      2.7.13-10.fc26        @commandline      6.3 M
     replacing  python-libs.x86_64 2.7.13-2.fc25
 python2-tkinter      x86_64      2.7.13-10.fc26        @commandline      396 k
     replacing  tkinter.x86_64 2.7.13-2.fc25
 python2-tools        x86_64      2.7.13-10.fc26        @commandline      847 k
     replacing  python-tools.x86_64 2.7.13-2.fc25

Transaction Summary
================================================================================
Install  5 Packages

Total size: 8.0 M
Installed size: 30 M
Is this ok [y/N]: y
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1 
  Installing       : python2-libs-2.7.13-10.fc26.x86_64                    1/10 
  Running scriptlet: python2-libs-2.7.13-10.fc26.x86_64                    1/10 
  Installing       : python2-2.7.13-10.fc26.x86_64                         2/10 
  Installing       : python2-tkinter-2.7.13-10.fc26.x86_64                 3/10 
  Installing       : python2-tools-2.7.13-10.fc26.x86_64                   4/10 
  Installing       : python2-devel-2.7.13-10.fc26.x86_64                   5/10 
  Obsoleting       : python-devel-2.7.13-2.fc25.x86_64                     6/10 
  Obsoleting       : python-tools-2.7.13-2.fc25.x86_64                     7/10 
  Obsoleting       : tkinter-2.7.13-2.fc25.x86_64                          8/10 
  Obsoleting       : python-2.7.13-2.fc25.x86_64                           9/10 
  Obsoleting       : python-libs-2.7.13-2.fc25.x86_64                     10/10 
  Running scriptlet: python-libs-2.7.13-2.fc25.x86_64                     10/10 
  Verifying        : python2-devel-2.7.13-10.fc26.x86_64                   1/10 
  Verifying        : python2-libs-2.7.13-10.fc26.x86_64                    2/10 
  Verifying        : python2-tkinter-2.7.13-10.fc26.x86_64                 3/10 
  Verifying        : python2-tools-2.7.13-10.fc26.x86_64                   4/10 
  Verifying        : python2-2.7.13-10.fc26.x86_64                         5/10 
  Verifying        : tkinter-2.7.13-2.fc25.x86_64                          6/10 
  Verifying        : python-devel-2.7.13-2.fc25.x86_64                     7/10 
  Verifying        : python-2.7.13-2.fc25.x86_64                           8/10 
  Verifying        : python-libs-2.7.13-2.fc25.x86_64                      9/10 
  Verifying        : python-tools-2.7.13-2.fc25.x86_64                    10/10 

Installed:
  python2.x86_64 2.7.13-10.fc26         python2-devel.x86_64 2.7.13-10.fc26    
  python2-libs.x86_64 2.7.13-10.fc26    python2-tkinter.x86_64 2.7.13-10.fc26  
  python2-tools.x86_64 2.7.13-10.fc26  

Complete!

Comment 13 Adam Williamson 2017-05-31 18:47:18 UTC
We're interpreting the package set criterion quite strictly (we rejected the FreeIPA upgrade issue because of it), so on that basis I'm -1 to this, if none of the blocking package sets actually includes it.

Comment 14 Miro Hrončok 2017-06-01 09:33:57 UTC
Rawhide build failed on s390x :( will investigate.

Comment 15 Kamil Páral 2017-06-01 10:19:44 UTC
(In reply to Adam Williamson from comment #13)
> We're interpreting the package set criterion quite strictly (we rejected the
> FreeIPA upgrade issue because of it), so on that basis I'm -1 to this, if
> none of the blocking package sets actually includes it.

I'm not sure how we interpret a blocking package set. Server DVD includes it, so it's part of it. But it doesn't install it by default, unless you request to install one of the available "addons" in anaconda (I didn't bother to figure out which one(s)).

Comment 16 Charalampos Stratakis 2017-06-01 10:34:36 UTC
(In reply to Kamil Páral from comment #15)
> (In reply to Adam Williamson from comment #13)
> > We're interpreting the package set criterion quite strictly (we rejected the
> > FreeIPA upgrade issue because of it), so on that basis I'm -1 to this, if
> > none of the blocking package sets actually includes it.
> 
> I'm not sure how we interpret a blocking package set. Server DVD includes
> it, so it's part of it. But it doesn't install it by default, unless you
> request to install one of the available "addons" in anaconda (I didn't
> bother to figure out which one(s)).

Is it possible to figure that out, in order to determine if we can eliminate the python2 dependency from there as well?

Comment 17 Kamil Páral 2017-06-01 11:14:59 UTC
(In reply to Charalampos Stratakis from comment #16)
> Is it possible to figure that out, in order to determine if we can eliminate
> the python2 dependency from there as well?

I'm talking about F25 Server DVD. I don't think it matters what addon depends on it, the important fact is that at least one does. All of this is relevant only for our blocker discussion, the python spec fix we need is to just provide correct obsoletes, that's it :)

Comment 18 Miro Hrončok 2017-06-01 11:27:55 UTC
Second build passed. Magic.

Rawhide https://koji.fedoraproject.org/koji/taskinfo?taskID=19798533

Comment 19 Fedora Update System 2017-06-01 11:29:44 UTC
python2-2.7.13-10.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-a25eb36de1

Comment 20 Charalampos Stratakis 2017-06-01 11:58:02 UTC
(In reply to Kamil Páral from comment #17)
> (In reply to Charalampos Stratakis from comment #16)
> > Is it possible to figure that out, in order to determine if we can eliminate
> > the python2 dependency from there as well?
> 
> I'm talking about F25 Server DVD. I don't think it matters what addon
> depends on it, the important fact is that at least one does. All of this is
> relevant only for our blocker discussion, the python spec fix we need is to
> just provide correct obsoletes, that's it :)

It might not be relevant for the blocker discussion however, it does matter from the Python's SIG POV as we there was an effort to have Python 3 as the default python interpreter. So if there is actually 1 package (or maybe its dependencies) that can be ported and then the Server DVD will not drag the python2 interpreter that is a good step towards that effort.

Comment 21 Petr Viktorin 2017-06-01 12:01:52 UTC
It's Samba. It's being worked on, but it'll still take some time to move it off Python 2.

Comment 22 Stephen Gallagher 2017-06-01 12:15:58 UTC
I'm also -1 to blocking Beta compose on this issue. It's problematic only on upgrades, so even if we don't get the fixed Obsoletes: onto the disk, it shouldn't matter (we don't support upgrading via install media).

I'm +1 to a 0day blocker since it will cause issues on upgrade. I think in that case it violates the criterion "The upgraded system must include all packages that would be present on the system after a default installation from install media, plus any packages the user previously had (minus any obsolete content)." Since the apparent behavior here is that dnf is choosing to retain the F25 packages rather than upgrade to the F26 python2 packages.

Comment 23 Adam Williamson 2017-06-01 17:12:40 UTC
Kamil: it seems like you're right, and we've never strictly defined the term, unless I can't find the definition! But I've always understood it to mean "the default package sets on the release blocking images", not "all packages included on a release blocking image". This seems consistent with the decision made about the FreeIPA upgrade bug - if we were treating upgrade issues in any package available from the Server DVD as blocking, that bug should've been accepted.

Comment 24 Miro Hrončok 2017-06-01 20:38:44 UTC
I've pushed similar fix to python2-docs (F26 and Rawhide). But I haven't built it, because no newer version is yet in F25 or F24 and it will only get bumped there if Python 2.7.14 ever happens and in that case it will be built in F26 and Rawhide as well.

http://pkgs.fedoraproject.org/cgit/rpms/python2-docs.git/commit/?id=c51ea59c05bb58a7b7826003817e8469df5a1a01

Comment 25 Adam Williamson 2017-06-02 21:15:20 UTC
Discussed at 2017-06-01 Fedora 26 Beta Go/No-Go meeting #2, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2017-06-01/f26-beta-go-no-go-meeting.2017-06-01-17.00.log.html . Rejected as a blocker on the basis that we consider 'release blocking package sets' to include only the *default* package sets installed by release blocking images, and present information is that none of these are affected by the bug. However, accepted as a freeze exception issue as it would be good to push the fix for this stable ASAP so folks who *do* have the affected packages installed can upgrade cleanly.

Comment 26 Fedora Update System 2017-06-04 05:12:41 UTC
python2-2.7.13-10.fc26 has been pushed to the Fedora 26 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-2017-a25eb36de1

Comment 27 Miro Hrončok 2017-06-04 14:04:37 UTC
Kamil, could you test upgrading Fedora 25 with python2 installed to Fedora 26 with testing enabled to see if those packages get updated?

Comment 28 Kamil Páral 2017-06-05 08:50:48 UTC
It's working now.

Comment 29 Fedora Update System 2017-06-09 19:20:37 UTC
python2-2.7.13-10.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, 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.