Bug 1706315 - Dependancy issues for python3-magic
Summary: Dependancy issues for python3-magic
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: file
Version: 30
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-05-04 09:11 UTC by Frank Crawford
Modified: 2019-05-14 13:07 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-05-14 13:07:54 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Frank Crawford 2019-05-04 09:11:27 UTC
Description of problem:

[frank@agc s3cmd]$ dnf --releasever=30 deplist s3cmd
Last metadata expiration check: 0:35:25 ago on Sat 04 May 2019 17:13:52 AEST.
package: s3cmd-2.0.2-2.fc30.noarch
  dependency: /usr/bin/python3
   provider: python3-3.7.3-1.fc30.i686
   provider: python3-3.7.3-1.fc30.x86_64
  dependency: python(abi) = 3.7
   provider: python3-3.7.3-1.fc30.i686
   provider: python3-3.7.3-1.fc30.x86_64
  dependency: python3-dateutil
   provider: python3-dateutil-1:2.8.0-1.fc30.noarch
  dependency: python3-magic
   provider: python3-magic-5.36-2.fc30.noarch
  dependency: python3.7dist(python-dateutil)
   provider: python3-dateutil-1:2.8.0-1.fc30.noarch
  dependency: python3.7dist(python-magic)

[root@bits p]# rpm -q --provides -p python3-magic-5.36-2.fc30.noarch.rpm 
python3-magic = 5.36-2.fc30
python3.7dist(file-magic) = 0.4.0
python3dist(file-magic) = 0.4.0

Version-Release number of selected component (if applicable):
python3-magic-5.36-2.fc30.noarch.rpm

How reproducible:
100%

Steps to Reproduce:
See above

Actual results:
The expected automatically generated dependency is expected to be python-magic, but the actual provided automatically generated provides is file-magic.

Expected results:
Generate provide in python3-magic is python-magic

Additional info:
This issue is due to enabling the python automatic dependency generator in F30, where as previously it was optional, see https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ and initially came from BZ1706260.

Comment 1 Kamil Dudka 2019-05-06 08:18:53 UTC
I think this problem needs to be fixed in the s3cmd package.  The documentation you refer to says that "standardized name (i.e. dist name, name on PyPI) of the packaged software" should be used.  The standardized name for python*-magic is "file-magic":

    https://github.com/file/file/blob/FILE5_36/python/setup.py#L11

I checked older builds of the file package and they also used python*dist(file-magic) in provides.  I do not think we should suddenly change it now to satisfy dependencies of another package.

Comment 2 Frank Crawford 2019-05-06 09:49:15 UTC
(In reply to Kamil Dudka from comment #1)
> I think this problem needs to be fixed in the s3cmd package.  The
> documentation you refer to says that "standardized name (i.e. dist name,
> name on PyPI) of the packaged software" should be used.  The standardized
> name for python*-magic is "file-magic":
> 
>     https://github.com/file/file/blob/FILE5_36/python/setup.py#L11

Yes, and to make it worse there are two different but similar modules, i.e. file-magic and python-magic, but in Fedora there appears to be only the one based on file-magic.

> I checked older builds of the file package and they also used
> python*dist(file-magic) in provides.  I do not think we should suddenly
> change it now to satisfy dependencies of another package.

Unfortunately, this only really hits with Fedora 30 and the change to the default enabling automatic dependency generation.

However, I understand if you can't easily fix the issue, I'll just leave the workaround in s3cmd in place and see what they feel upstream about updating the dependencies.

Comment 3 Kamil Dudka 2019-05-06 10:06:28 UTC
(In reply to Frank Crawford from comment #2)
> Unfortunately, this only really hits with Fedora 30 and the change to the
> default enabling automatic dependency generation.

Does not it rather mean that the mentioned Fedora 30 change triggered a problem in the s3cmd package?

python3-magic has pretty consistent RPM metadata before/after the change, unlike s3cmd.

Comment 4 Kamil Dudka 2019-05-06 10:15:24 UTC
Note that the `file-magic` name was introduced in 2015.  It used to be named `Magic file extensions` before the following change:

https://github.com/file/file/commit/8048d19f

Comment 5 Frank Crawford 2019-05-06 10:45:43 UTC
(In reply to Kamil Dudka from comment #3)
> (In reply to Frank Crawford from comment #2)
> > Unfortunately, this only really hits with Fedora 30 and the change to the
> > default enabling automatic dependency generation.
> 
> Does not it rather mean that the mentioned Fedora 30 change triggered a
> problem in the s3cmd package?
> 
> python3-magic has pretty consistent RPM metadata before/after the change,
> unlike s3cmd.

Kind of.  Prior to F30, Fedora ignore the setup.py file and relied on the manually added definitions in the spec file.  Now it is using those definitions, and s3cmd is willing to use any of three different packages that offer similar functionality.

So, it isn't really a failure of python3-magic itself, but more an issue that different dependency names not match, i.e. the Require statement is python3-magic, but the automatic requirement would be file-magic.  My assumption at the start of this was that they would match, but that isn't true, and I can see why now.

Except for raising conciousness of the issue, I don't expect anything to change in python3-magic to address this.

Comment 6 Kamil Dudka 2019-05-06 11:23:21 UTC
The dependency on `python-magic` in s3cmd upstream was introduced by the following commit:

https://github.com/s3tools/s3cmd/commit/73dbfa4a

What is the actual provider of `python-magic` that s3cmd's upstream relies on?

Is it a different implementation than what we use in Fedora?

If not, why does it use a different name than file's upstream?

Comment 7 Frank Crawford 2019-05-06 11:42:23 UTC
Looking through the code, it only uses a small part of the functionality, but tests for that in the following packages, in order:

python-magic
file-magic
filemagic

so, the provider in Fedora works, but is not the first choice.

Comment 8 Gwyn Ciesla 2019-05-08 14:40:01 UTC
Affecting python-Mastodon.

Comment 9 Kamil Dudka 2019-05-09 01:27:54 UTC
(In reply to Gwyn Ciesla from comment #8)
> Affecting python-Mastodon.

Same questions here:

What is the actual provider of `python-magic` that Mastodon.py's upstream relies on?

Is it a different implementation than what we use in Fedora?

If not, why does it use a different name than file's upstream?

Comment 10 Gwyn Ciesla 2019-05-09 14:14:51 UTC
It says python-magic in setup.py, but import magic in the code.

Comment 11 Kamil Dudka 2019-05-09 16:38:00 UTC
I know that s3cmd and Mastodon.py require 'python-magic' in setup.py but I do not know which implementations of 'magic' this requirement resolves to in which environments.

Comment 12 Frank Crawford 2019-05-10 10:48:07 UTC
I just had a look at both the Mastodon code and the python-mastodon spec file, and in this case Mastodon only has python-magic as an optional product, and works fine without it.

Previously the spec file didn't include it as a requirement, so didn't pull it in at all.  Now the autogeneration from the cfg file is trying to pull it in.

Also, if it did actually match, it would probably fail as it is the wrong version of magic.

I think the short term fix is the same as I did in s3cmd, i.e. add the following command:

%{?python_disable_dependency_generator}

Although longer term it may be a patch to edit the cfg file.

Comment 13 Gwyn Ciesla 2019-05-10 13:28:18 UTC
Thanks, I'll do that for Mastodon.

Comment 14 Kamil Dudka 2019-05-14 13:07:54 UTC
Closing for now.  Feel free to reopen if you know answers to the questions in comment #9.


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