#2 Add cairocffi[xcb] subpackage
Closed 9 months ago by churchyard. Opened 9 months ago by churchyard.
rpms/ churchyard/python-cairocffi extras  into  master

file modified
+7 -1
@@ -2,7 +2,7 @@ 

  

  Name:           python-cairocffi

  Version:        1.1.0

- Release:        3%{?dist}

+ Release:        4%{?dist}

  Summary:        cffi-based cairo bindings for Python

  License:        BSD

  URL:            https://pypi.python.org/pypi/cairocffi/
@@ -41,6 +41,9 @@ 

  

  %description -n python3-cairocffi %_description

  

+ %{?python_extras_subpkg:%python_extras_subpkg -n python3-cairocffi -i %{python3_sitelib}/*.egg-info xcb}

+ 

+ 

  %prep

  %autosetup -n cairocffi-%{version}

  rm -rf %{srcname}.egg-info
@@ -61,6 +64,9 @@ 

  %{python3_sitelib}/*

  

  %changelog

+ * Fri Jul 10 2020 Miro Hrončok <mhroncok@redhat.com> - 1.1.0-4

+ - Add cairocffi[xcb] subpackage

+ 

  * Tue May 26 2020 Miro Hrončok <mhroncok@redhat.com> - 1.1.0-3

  - Rebuilt for Python 3.9

  

I could technically remove:

# required by cairocffi.pixbuf
Requires:       python3-xcffib >= 0.3.2

and replace it with:

Recommends:     python3-cairocffi+xcb

Please let me know if I should. (It can also be done in a backwards compatible way.)

I could also move %{python3_sitelib}/cairocffi/xcb.py to the new subpackage, however the file is tiny.

sorry, somehow I missed this PR.

I'll try your changes to get a feeling if we should move 'xcb.py' into a subpackage. Generally I like depending on RPM's dependencies ("if I install python3-cairocffi I can use all provided files without ImportError") so I tend to having xcb.py in that subpackage.

@brouhaha , @jdulaney If you have different opinion or if you like to handle this, please just speak up here :-)

2 things to consider:

  • leaving the file where it is now is consistent with upstream
  • moving the file to the extra subpackage while preserving pre-fedora-33 compatibility will be a tad verbose

I checked the upstream sources a bit closer and it seems to me as if cairocffi's extra package is special snowflake. Basically the build process checks if xcffib is available and generates different code in …/cairocffi/_generated/.

The xcb extra package is only used to encode the dependency xcffib >= 0.3.2. If xcffib was available during the build phase, we always need it also at runtime as the code does not make any attempt to check for the presence of xcffib later.

  • We need xcffib support for WeasyPrint so we can not just remove it.
  • We can not move any files to a subpackage nor remove any dependencies from the main package.

Does the extras subpackage make any sense here? I guess it won't hurt but actually the whole subpackage seems to be a bit overblown. Also upstream does not use the extras subpackage in their installation docs anymore (commit 378be07e).

Does the extras subpackage make any sense here?

We need something to provide it, because other packages will require it:

$ repoquery --repo=python-extras --whatrequires 'python3.9dist(cairocffi\[xcb\])'
qtile-0:0.14.2-2.fc33.noarch

http://copr.fedorainfracloud.org/coprs/g/python/python-extras/

I suppose the provide could be added to the main package instead, manually, with a comment.

I suppose the provide could be added to the main package instead, manually, with a comment.

Shall I do that instead?

I suppose the provide could be added to the main package instead, manually, with a comment.

Actually I like that solution best as cairocffi[xcb] and cairocffi are actually the same thing after building. Is there a macro which can be used to generate the same provides as %python_extras_subpkg ?

In particular that macro shortens the version number from 1.1.0 (%{version}}) to 1.1.

(ah, just saw your extra comment - sorry for the delay: vacation time here)

Shall I do that instead?

Yes, please.

Pull-Request has been closed by churchyard

9 months ago
Metadata