Bug 1793689 - python3-magic should be renamed to python3-file-magic
Summary: python3-magic should be renamed to python3-file-magic
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: file
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Vincent Mihalkovič
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: python-magic
TreeView+ depends on / blocked
 
Reported: 2020-01-21 20:08 UTC by Robert-André Mauchin 🐧
Modified: 2025-01-27 17:00 UTC (History)
7 users (show)

Fixed In Version: file-5.38-3.fc33
Clone Of:
Environment:
Last Closed: 2020-03-20 13:30:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Robert-André Mauchin 🐧 2020-01-21 20:08:45 UTC
Naming the python subpackage python3-magic prevents the packaging of https://pypi.org/project/python-magic The version you provide is https://pypi.org/project/file-magic/ and should be named as such.

Many SPEC requiring python3-magic in Fedora actually expect https://pypi.org/project/python-magic, not https://pypi.org/project/file-magic/ 

python3-magic-5.38-1.fc32.noarch
alot-0.8.1-5.fc32.noarch               expects      https://pypi.org/project/python-magic
diffoscope-134-1.fc32.noarch                        https://pypi.org/project/file-magic/
python3-Mastodon-1.5.0-1.fc32.noarch                https://pypi.org/project/python-magic
python3-jira-2.0.0-6.fc32.noarch                    https://pypi.org/project/filemagic/ (a different one again)
retrace-server-1.19.0-5.fc32.noarch                 https://pypi.org/project/python-magic
rpmlint-1.11-4.fc32.noarch                          https://pypi.org/project/file-magic/
s3cmd-2.0.2-7.fc32.noarch                           https://pypi.org/project/python-magic as first option, https://pypi.org/project/file-magic/ as backup 
Carla-2.1-2.beta13322c9f.fc32.src                   https://pypi.org/project/file-magic/

Comment 1 Kamil Dudka 2020-01-22 09:23:12 UTC
I do not think that the subpackage itself needs to be renamed.  It already has provides that should emulate the pypi dependency scheme:

kdudka@f32 ~ % rpm -q python3-magic --provides
python3-magic = 5.38-1.fc32
python3.8dist(file-magic) = 0.4
python3dist(file-magic) = 0.4

It might need some tweaks though.  Bug #1706315 seems related.

Comment 2 Robert-André Mauchin 🐧 2020-01-22 13:29:44 UTC
Yes it has provides but by using the name python3-magic it prevents the packaging of https://pypi.org/project/python-magic because the name are the same. The Pypi name is actually file-magic and should be used to free up python-magic for https://pypi.org/project/python-magic

Comment 3 Kamil Dudka 2020-01-22 14:51:08 UTC
OK, got it.  But we will have to make python3-file-magic provide python3-magic in order not to break the packages depending on its current name.  I guess that the packages that need pypi's python-magic will require it as python3*dist(python-magic) anyway, won't they?

Comment 4 Robert-André Mauchin 🐧 2020-01-22 17:26:51 UTC
(In reply to Kamil Dudka from comment #3)
> OK, got it.  But we will have to make python3-file-magic provide
> python3-magic in order not to break the packages depending on its current
> name.  I guess that the packages that need pypi's python-magic will require
> it as python3*dist(python-magic) anyway, won't they?

Current packages should be patched to either require python3.8dist(file-magic) or python3.8dist(python-magic). The whole list is in comment 1. I think if all packaqes  are patched,there's no need for the provide.

Comment 5 Kamil Dudka 2020-01-24 08:15:49 UTC
(In reply to Robert-André Mauchin from comment #4)
> I think if all packaqes  are patched,there's no need for the provide.

Nope.  There can be 3rd party packages relying on the current naming, which has been used for quite a long period of time.

Comment 6 Ben Cotton 2020-02-11 17:26:30 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 7 Fabian Affolter 2020-03-16 23:26:55 UTC
Kamil, can we please go on with the renaming process?

Comment 8 Kamil Dudka 2020-03-17 07:40:56 UTC
Yes.  My fellow Vincent Mihalkovic is going to take care of it as soon as he has the appropriate ACL bits granted in FAS.

Comment 10 Adam Williamson 2025-01-25 00:15:38 UTC
As Frank Dana noted in https://discussion.fedoraproject.org/t/is-it-possible-to-unravel-the-python-magic-packaging-clusterfsck/136792 , this has caused a real mess to exist. I don't think two packages both providing a library called 'magic' ought to exist in the same distribution, it's insanity. One of the libraries needs to be renamed.

This resulted in a broken 389-ds-base update today: https://bodhi.fedoraproject.org/updates/FEDORA-2025-d546c237ea#comment-3931147

Comment 11 Vincent Mihalkovič 2025-01-27 11:53:47 UTC
Does this problem also occur with: https://src.fedoraproject.org/rpms/file/c/81910b7d885873b6fdfd4e750875172f1e031179?branch=rawhide - https://src.fedoraproject.org/rpms/file/pull-request/33
Should I backport the patch to f42?

Comment 12 Adam Williamson 2025-01-27 17:00:26 UTC
Yes, it would have done. 389-ds-base was explicitly using and relying on the real python3-magic, but that means it cannot be installed any time python3-file-magic is installed. Having python3-file-magic installed is commonly the case for two reasons:

1. sos recommends python3-file-magic, and sos in in the 'standard' comps group (so most non-minimal Fedora installs have python3-file-magic OOTB)
2. rpmlint requires python3-file-magic (so Fedora packagers commonly have it installed even if they don't have sos)

Given this, packages using python3-magic feel like footguns to me...


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