python3-magic was recently renamed to python3-file-magic to avoid unnecessary conflicts:

    bug #1793689

the renaming did indeed take place but there is still a problem of both packages naturally conflicting and python-file-magic obsoleting python-magic stopping people with python-file-magic installed from installing any package that depends on python-magic

Kamil, this is wrong. I can't install Lutris on F33:

$ sudo dnf install lutris
Last metadata expiration check: 1:42:52 ago on Fri 20 Nov 2020 10:14:53 AM CET.
Dependencies resolved.

 Problem: problem with installed package python3-file-magic-5.39-3.fc33.noarch
  - package python3-file-magic-5.39-3.fc33.noarch conflicts with python3-magic < 5.39-3.fc33 provided by python3-magic-0.4.15-4.fc33.noarch
  - installed package python3-file-magic-5.39-3.fc33.noarch obsoletes python3-magic < 5.39-3.fc33 provided by python3-magic-0.4.15-4.fc33.noarch
  - package python3-file-magic-5.39-3.fc33.noarch obsoletes python3-magic < 5.39-3.fc33 provided by python3-magic-0.4.15-4.fc33.noarch
  - package lutris-0.5.8-1.fc33.x86_64 requires python3.9dist(python-magic), but none of the providers can be installed
  - cannot install the best candidate for the job

Lutris requires python3-magic, while rpmlint (a dep for fedpkg) requires python3-file-magic, and those packages conflict. They both want to install /usr/lib/python3.9/site-packages/magic.py. This needs to be solved somehow, and I don't know how, I'm not a python packaging expert.

CC Miro Hrončok for advice, thanks!

Miro, for reference, we're talking about these two PyPI packages:
https://pypi.org/project/file-magic/
https://pypi.org/project/python-magic/

(Making this bug public, because there is no private data here, I assume it was a mistake by the reporter)

There are several problems here:

1) python3-file-magic provides and obsoletes python3-magic, hence no package can reasonably use python3-magic as a dependency at all:

$ repoquery --repo=rawhide --obsoletes python3-file-magic
python3-magic < 5.39-3.fc34

$ repoquery --repo=rawhide python3-magic
python3-magic-0:0.4.15-4.fc33.noarch

$ sudo dnf upgrade
...
Installing:
 python3-file-magic  noarch  5.39-3.fc34  fedora  18 k
     replacing  python3-magic.noarch 0.4.15-4.fc33

This might be solvable by doing both of the following:

 - fix the obsoleted version instead of using %{version}-%{release}
 - introduce epoch to python3-magic


2) The packages have implicit file conflict. This should (at least for start) be accompanied by an explicit RPM Conflicts. That way, the packages still won't be able to install at the same time, but at least dnf will know before attempting to do so.


$ repoquery --repo=rawhide -l python3-magic
...
/usr/lib/python3.9/site-packages/magic.py
...

$ repoquery --repo=rawhide -l python3-file-magic
...
/usr/lib/python3.9/site-packages/magic.py
...



It is literately impossible to solve this conflict without also patching all consumers of (at least one of) the packages to either use a different module name or different sys.path. If you have both packages installed at once and do "import magic" you will either have one or another.

The only possible way of solving this is to:

a) See if the API is compatible or not. If it is, try seeing which of the packages is "better" (less dead upstream, more features, etc.) and switch all of the depending packages to it. If not, try to make them compatible, or...

b) See if one of the upstreams is willing to change the module name. That would still require fixing all the dependents, but at least it would have not been a downstream only hack.

c) Cry.

a) python-file-magic and python-magic are not API compatible for example:
to use each of the libraries on a file you have to do

python-file-magic: magic.detect_from_filename
python-magic: magic.from_file

b) python-magic seems to be more up to date but I don't think simply migrating to it a viable option

With lutris there is the option of adding support for python-file-magic alongside python-magic but that does not solve the problem only postpone it(In reply to Kamil Páral from comment #4)

> (Making this bug public, because there is no private data here, I assume it
> was a mistake by the reporter)

This was a mistake on my part, I am always having trouble finding my way around Bugzilla

One interesting note is that if you look at the PKG-INFO file included within python3-file-magic, the version indicated is 0.4.0 which doesn't correlate with the main version of the file package.  python3-magic has 0.4.15 currently.  I do not know if this is mere coincidence.

Both modules are at least a decade old; python3-magic dates from 2010 and python3-file-magic from 2003.  Surely this conflict must have been discussed somewhere before, and indeed while looking I found https://github.com/ahupp/python-magic/issues/21.  I made a note of this bugzilla ticket there.

Hey I'm the Lutris package maintainer checking in.

I've passed this bug onto the dev-team & asked them if they've run into the issue on other distributions. I'll let you know what they say.

As to actually resolving the issue I'd be quite out of my depth technically, so I'm glad that there are others working on this.

According to https://github.com/ahupp/python-magic/issues/21, Mageia has also recently run into this and may take the route of patching Lutris.  It might be useful to communicate with them as well, at least to get a temporary solution.

Also according to that issue, the maintainer of the standalone module was going to work on compatibility code to implement the API of the module in the file source but that doesn't seem to have happened yet.  Anyway, I'm far from the expert here so I'll leave the solutions to those who know better.

I got this response from the Lutris devs (not that this resolves our problem):

"Did a very quick source dive, it's used as part of the new automatic installers for gog and humble. Lutris degrades gracefully if it's not present — the install will complete, but you'll need to manually select the executable in the game's options afterward. Installers from Lutris.net should continue to work normally."

For someone with more experience packaging than I have, is there a way to allow installations without this dependency (but nonetheless suggest it) until we fix this issue given that its not integral to the functioning of Lutris?

(In reply to Chris King from comment #10)
> allow installations without this dependency

a simple sed should do the job

sed -i "s/python-magic//g" setup.py

That would leave this:

    install_requires=[
        'PyYAML',
        'PyGObject',
        'evdev',
        'requests',
        ''
    ],


What about:

sed -i '/python-magic/d' setup.py

(In reply to Miro Hrončok from comment #12)
> What about:
> 
> sed -i '/python-magic/d' setup.py
an empty string would be ignored so doing either of the sed's would lead to the same behavior but perhaps this deleting the line is the better option

the hard dependency on python-magic in lutris has been changed to allow file-magic to act as an alternative
https://github.com/lutris/lutris/commit/116dac759db01b50dd36b27fb66853c815d177ea

but this is issue still persists
I don't think either project is going to either implement the others API for compatibility or change their module name
so I propose a fourth solution:

d) a compatibility layer that will work with both libmagic wrappers and expose API endpoints available in both of them

I've updated the Lutris package with that edit. Sorry it took me so long to get around to this. The patch I've made (per your suggestions) removes python-file-magic altogether, along with the functionality it provides, unless I'm misunderstanding something. 

Hopefully we can get this bug sorted out soon so that Fedora users can have the functionality provided by python-file-magic in Lutris.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Still an issue on F35. This breaks mimetype.py plugin in eyeD3, for example. At minimum, the Obsoletes: python3-magic < 5.40-9.fc35 must be removed as it's just not true. Both projects are still actively developed.

Also, python-magic upstream implemented a compatibility layer: https://github.com/ahupp/python-magic/issues/21#issuecomment-936253287 that's present in 0.4.19+. I think it's high time to stop obsoleting python3-magic here.

Any updates on this?

(In reply to Dominik 'Rathann' Mierzejewski from comment #17)
> At minimum, the Obsoletes: python3-magic < 5.40-9.fc35 must be removed as
> it's just not true. Both projects are still actively developed.

The obsolete is there because the file's subpackage was originally named python3-magic (see bug #1793689).  If we remove it, it will complicate upgrades across major versions of CentOS.

(In reply to Kamil Dudka from comment #20)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #17)
> > At minimum, the Obsoletes: python3-magic < 5.40-9.fc35 must be removed as
> > it's just not true. Both projects are still actively developed.
> 
> The obsolete is there because the file's subpackage was originally named
> python3-magic (see bug #1793689).  If we remove it, it will complicate
> upgrades across major versions of CentOS.

Since python-magic implements a compatibility layer it should be fine to lower the obsoletes to versions under 0.4.20.


(In reply to Chris King from comment #19)
> Any updates on this?

In the time between opening this and now Lutris has implemented check for which package is installed and acted accordingly [1]
and now they have decided to outright vendor python-magic [2]

[1] https://github.com/lutris/lutris/pull/3320
[2] https://github.com/lutris/lutris/commit/fbdafa6eed4b9c750fc8881b920125d4495b6a4c#diff-85a93ccc27334ffc74985116d0b6a9b958611985db1c32376f0f3d61a148adab

_Iff_ python3-file-magic is going to obsolete python3-magic, it seems that it needs to provide python3.10dist(python-magic).  Right now, it prevents installing packages where upstream depends on python-magic, as rpmlint-2.3.0 does, for example.

This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Both packages still exist in rawhide.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

This happens (again) in rawhide if you have fedora-packager installed due to rpmlint's migration to pyproject.toml.
See attached links.

Merged in https://src.fedoraproject.org/rpms/rpmlint/c/e819bfc83a166abd6611bc9c987e8ee1f153b04c?branch=rawhide

FEDORA-2023-2ed6d85eb0 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-2ed6d85eb0

FEDORA-2023-2ed6d85eb0 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

I think this closure was a mistake. rpmlint update does not fix the conflict.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle.
Changing version to 42.