Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2245957 - The python-zeroconf package is not really noarch
Summary: The python-zeroconf package is not really noarch
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: python-zeroconf
Version: rawhide
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Miro Hrončok
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-10-24 19:13 UTC by Ben Beasley
Modified: 2023-10-26 14:51 UTC (History)
3 users (show)

Fixed In Version: python-zeroconf-0.118.0-2.fc40
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-10-25 12:28:12 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Ben Beasley 2023-10-24 19:13:52 UTC 
The python-zeroconf package has “BuildArch: noarch”, but it is installed to %{python3_sitearch} even when—as is presently the case—the optional Cython extensions are not compiled.

The result is that the package is not importable on some architectures, depending on which architecture it was build on. For example, when the builder was x86_64, the package is not importable on i686 because /usr/lib64/… is not in the Python path.

Reproducible: Always

Steps to Reproduce:
1. mock -r fedora-rawhide-i386 --clean
2. mock -r fedora-rawhide-i386 -i python3-zeroconf
3. mock -r fedora-rawhide-i386 --chroot 'python3 -c "import zeroconf"'
Actual Results:  
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'zeroconf'


Expected Results:  
No output because the module imported successfully.

There are three obvious paths forward:

1. Find a way to make the package install in %{python3_sitelib} instead of %{python3_sitearch}. Strongly consider explicitly exporting SKIP_CYTHON in %build to make sure the package remains pure-Python.

2. Let the package remain pure-Python (and strongly consider explicitly exporting SKIP_CYTHON in %build), but omit “BuildArch: noarch” and add “%global debug_package %{nil}” since the installation paths are arch-dependent.

3. Omit “BuildArch: noarch” and ensure the Cython extensions are actually compiled (and strongly consider exporting REQUIRE_CYTHON in %build to be explicit).

If you let me know what you want to do, I can try to offer a PR.
Comment 1 Peter Robinson 2023-10-24 19:21:16 UTC 
(In reply to Ben Beasley from comment #0)
> The python-zeroconf package has “BuildArch: noarch”, but it is installed to
> %{python3_sitearch} even when—as is presently the case—the optional Cython
> extensions are not compiled.

This package has evolved a lot since it was first packaged.

> builder was x86_64, the package is not importable on i686 because

TBH why do we care about i686?

> There are three obvious paths forward:
> 
> 1. Find a way to make the package install in %{python3_sitelib} instead of
> %{python3_sitearch}. Strongly consider explicitly exporting SKIP_CYTHON in
> %build to make sure the package remains pure-Python.
> 
> 2. Let the package remain pure-Python (and strongly consider explicitly
> exporting SKIP_CYTHON in %build), but omit “BuildArch: noarch” and add
> “%global debug_package %{nil}” since the installation paths are
> arch-dependent.
> 
> 3. Omit “BuildArch: noarch” and ensure the Cython extensions are actually
> compiled (and strongly consider exporting REQUIRE_CYTHON in %build to be
> explicit).
> 
> If you let me know what you want to do, I can try to offer a PR.

You don't explain what value/features the optional cpython functionality provides.
Comment 2 Ben Beasley 2023-10-24 19:40:24 UTC 
(In reply to Peter Robinson from comment #1)
> TBH why do we care about i686?

We care because having the installation directories vary randomly between /usr/lib/… and /usr/lib64/… depending on which builder the package happens to be built on is conceptually wrong, and we care because this “passes the buck” to dependent noarch packages, which will now randomly FTBFS when they happen to be assigned to an i686 builder.

> > If you let me know what you want to do, I can try to offer a PR.
> 
> You don't explain what value/features the optional cpython functionality
> provides.

Allegedly, it’s faster[1]. I don’t really care about that; I’m perfectly happy with any of the three options (pure Python, noarch, in %{python3_sitelib}; pure Python, arched, in %{python3_sitearch}; or Cythonized, arched, in %{python3_sitearch}). I’m not sure at a glance how to achieve option 1, though.

[1] https://github.com/python-zeroconf/python-zeroconf#python-zeroconf
Comment 3 Peter Robinson 2023-10-24 19:52:39 UTC 
It seems #2 is the most straight forward then? If so I'm fine with a PR for that.
Comment 4 Miro Hrončok 2023-10-25 06:04:01 UTC 
Thanks for the report.


I'd do #3 (assuming it can be done with reasonable effort). Most of the packages with optional extension modules actually ship them.

Only if #3 is hard, I'd fallback to #2.
Comment 5 Fedora Update System 2023-10-25 12:27:02 UTC 
FEDORA-2023-8f4f3cb695 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-8f4f3cb695
Comment 6 Fedora Update System 2023-10-25 12:28:12 UTC 
FEDORA-2023-8f4f3cb695 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.
Comment 7 Miro Hrončok 2023-10-26 14:51:30 UTC 
Considering the Cython compilation works out of the box: https://src.fedoraproject.org/rpms/python-zeroconf/pull-request/16
Note You need to log in before you can comment on or make changes to this bug.