Bug 1578359 - add ABRT's python2 packages as obsolete in rawhide
Summary: add ABRT's python2 packages as obsolete in rawhide
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-obsolete-packages
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1578134 1578514
TreeView+ depends on / blocked
 
Reported: 2018-05-15 11:53 UTC by Matej Habrnal
Modified: 2018-05-18 17:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-18 17:07:27 UTC


Attachments (Terms of Use)

Description Matej Habrnal 2018-05-15 11:53:06 UTC
Description of problem:
Can you please mark all ABRT's python2 packages as obsolete in rawhide?

python2-abrt
python2-abrt-addon
python2-abrt-container-addon

python2-libreport

python2-satyr

Thank you!

Comment 1 Jason Tibbitts 2018-05-15 14:41:26 UTC
Please describe the dependency problems which result from leaving these packages on the system.

Comment 2 Jason Tibbitts 2018-05-15 14:42:09 UTC
Also, please indicate the versions which need to be obsoleted.

Comment 3 Matej Habrnal 2018-05-16 13:07:33 UTC
(In reply to Jason Tibbitts from comment #1)
> Please describe the dependency problems which result from leaving these
> packages on the system.

There shouldn't be any Python2 packages in Fedora 29 (now rawhide). Listed packages have the same functionality as relevant Python3 packages. So I would say no problem will occur.

Is this package obsoleting only by packages version? Is it possible to obsolete by system version?

Comment 4 Jason Tibbitts 2018-05-16 16:52:13 UTC
I'm just asking for a quick summary of the actual dependency problems which occur on upgrades to be included in this ticket.  All you need to do is paste in some output from 'dnf system-upgrade' showing how the packages you want to be obsoleted cause problem.

This isn't about whether there will be any problems caused by the obsoletion of packages.  We don't force-remove packages from people's system without a good reason.  In the context of this package, that good reason is that there are actual dependency problems which prevent 'dnf system-upgrade' from working properly.

Also, your statement that there should be no python2 packages in rawhide is simply incorrect.  Depending on whether someone wants to maintain a python2 interpreter, there may be python2 packages in the distribution for years to come.  You can see the relevant packaging committee ticket at https://pagure.io/packaging-committee/issue/753 (but read the whole thing, as what we implemented was not identical to the original proposal).

Comment 5 Zbigniew Jędrzejewski-Szmek 2018-05-18 07:34:33 UTC
Hmm, is "quick summary of the actual dependency problems" really needed?. For pretty much any package, that is a) architecture specific, or b) has any versioned dependencies on any packages that could be reasonably upgraded, an upgrade issue is bound to occur when upgrading to the next version of Fedora.

In particular, looking at python2-abrt:
$ rpm -q -R python2-abrt
abrt = 2.10.7-1.fc27         <--- immediate issue when abrt is upgraded
abrt-dbus = 2.10.7-1.fc27    <--- immediate issue when abrt is upgraded
abrt-libs = 2.10.7-1.fc27    <--- immediate issue when abrt is upgraded
dbus-python
libabrt.so.0()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libgio-2.0.so.0()(64bit)     <--- potential issue on so-bump
libglib-2.0.so.0()(64bit)    <--- potential issue on so-bump
libgobject-2.0.so.0()(64bit) <--- potential issue on so-bump
libreport-python
libreport.so.0()(64bit)      <--- potential issue on so-bump
libsatyr.so.3()(64bit)       <--- potential issue on so-bump
python(abi) = 2.7
python2-gobject-base
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PartialHardlinkSets) <= 4.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)

If we consider any upgrade that requires using --allowerasing to be a bug, we can pretty much assume that almost any obsoleted python2 subpackage will cause problems sooner or later. It'd be a rare package that causes no issues whatsoever.

Comment 6 Matej Habrnal 2018-05-18 08:41:51 UTC
Thank you for the explanation.

Since we use Python3 packages instead of Python2 there are no related Python2 packages in Fedora 29 and this breaks dnf update.

The error for libreport packages is following (bz#578514):

On the current rawhide attempt to do 'dnf update libreport' results in

Error: 
 Problem: cannot install both libreport-2.9.5-1.fc29.x86_64 and libreport-2.9.4-1.fc29.x86_64
  - package python2-libreport-2.9.4-1.fc29.x86_64 requires libreport = 2.9.4-1.fc29, but none of the providers can be installed
  - cannot install the best update candidate for package libreport-2.9.4-1.fc29.x86_64
  - problem with installed package python2-libreport-2.9.4-1.fc29.x86_64

A similar error occurs for ABRT (bz#1578134).

We wanted to add obsolete to our spec files but it makes no sense to us that Python3 package obsolete Python2 package. Therefore, we decided to add obsolete to this package.

The obsolete versions are:
python2-abrt < 2.10.10
python2-abrt-addon < 2.10.10
python2-abrt-container-addon < 2.10.10

python2-libreport < 2.9.6

python2-satyr < 0.27

Comment 7 Jason Tibbitts 2018-05-18 17:07:27 UTC
Done and built in rawhide (fedora-obsolete-packages-29-9, https://koji.fedoraproject.org/koji/taskinfo?taskID=27044649).


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