I follow your reasoning and I think your conclusion is reasonable. On the other hand, I don’t think it would be an undue burden for packagers to have to add a manual “BuildRequires:” on a -devel package when building compiled Python extensions linked against another Python package’s C API, just as would be needed for a pure C or C++ library. I am thus on the fence about whether the conditional Requires is the best way to go.

In any case, the most notable package that offers a C API used by other Python extensions is certainly numpy. Currently, it does not provide a python3-numpy-devel subpackage at all. No matter what we decide the best practice should be, we should probably make sure numpy follows it.

It may be that the conditional Requires is a good approach for adding python3-*-devel subpackages to packages that lack them without having to make mass changes to dependent packages’ spec files, even if we don’t end up recommending that approach for the general case.

On 2/17/23 09:38, Miro Hrončok wrote:

Hello Pythonistats and packaging folks.

Tomáš (CCed) approached me today with an interesting question. A Python package he is packaging into RPM (python3-rapidfuzz) installs some development files (.h and .pxd).

Tomáš queried upstream about those files to figure out if they should be installed or if they are only needed to build the package itself. Upstream responded:

...

rapidfuzz.h and __init__.pxd provide a capi for rapidfuzz, which

allows users

...

to write their own similarity metrics in C/C++/Cython, which can be

called by

...

rapidfuzz in a more performant way through this C-API. For this reason the header file should be part of the installation

as well.

OK, we want to ship them. Our packaging guidelines however say:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages

...

Specifically, -devel packages must be used to contain files which are intended solely for development or needed only at build-time. This

is done to

...

minimize the install footprint for users. There are some types of

files which

...

almost always belong in a -devel package:   - Header files...

So from our guidelines perspective, the files would go to python3-rapidfuzz-devel. The way we packaged Python in 201x, this would be the end of it.

However, in this decade with automatic Python BuildRequires, we could easily end up in this situation:

1. a Python package lists rapidfuzz as a build requirement  2. %pyproject_buildrequires generates a dependency on python3dist(rapidfuzz)  3. only python3-rapidfuzz is pulled  4. %build wants to use rapidfuzz.h  5. packager needs to manually BuildRequire python3-rapidfuzz-devel

To avoid (5), my suggestion was to add the following requirement to python3-rapidfuzz:

Requires: (python3-rapidfuzz-devel%{?_isa} =              %{?epoch:%{epoch}:}%{version}-%{release} if python3-devel)

That way, application packages that pull in pytohn3-rapidfuzz as a runtime dependency won't get it (we are minimizing the install footprint for users), but users who build stuff (including RPM packages) will get it (we make automatically generated dependencies work as intended).

(Of course, users who have python3-devel installed for reasons other than rapidfuxx will still get the files, but the assumption here is that users who install -devel packages intent to /generally/ build stuff.)

Is that a good suggestion? And if so, should it be a general recommendation for such cases?

Am 17.02.23 um 15:38 schrieb Miro Hrončok:

Hello Pythonistats and packaging folks.

Tomáš (CCed) approached me today with an interesting question. A Python package he is packaging into RPM (python3-rapidfuzz) installs some development files (.h and .pxd).

Tomáš queried upstream about those files to figure out if they should be installed or if they are only needed to build the package itself. Upstream responded:

...

rapidfuzz.h and __init__.pxd provide a capi for rapidfuzz, which

allows users

...

to write their own similarity metrics in C/C++/Cython, which can be

called by

...

rapidfuzz in a more performant way through this C-API. For this reason the header file should be part of the installation as

well.

OK, we want to ship them. Our packaging guidelines however say:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages

...

Specifically, -devel packages must be used to contain files which are intended solely for development or needed only at build-time. This is

done to

...

minimize the install footprint for users. There are some types of

files which

...

almost always belong in a -devel package:   - Header files...

So from our guidelines perspective, the files would go to python3-rapidfuzz-devel. The way we packaged Python in 201x, this would be the end of it.

With my former FPC-hat on, this should still be the way to go.

However, in this decade with automatic Python BuildRequires, we could easily end up in this situation:

1. a Python package lists rapidfuzz as a build requirement  2. %pyproject_buildrequires generates a dependency on python3dist(rapidfuzz)  3. only python3-rapidfuzz is pulled  4. %build wants to use rapidfuzz.h  5. packager needs to manually BuildRequire python3-rapidfuzz-devel

To avoid (5), my suggestion was to add the following requirement to python3-rapidfuzz:

Requires: (python3-rapidfuzz-devel%{?_isa} =              %{?epoch:%{epoch}:}%{version}-%{release} if python3-devel)

That way, application packages that pull in pytohn3-rapidfuzz as a runtime dependency won't get it (we are minimizing the install footprint for users), but users who build stuff (including RPM packages) will get it (we make automatically generated dependencies work as intended).

(Of course, users who have python3-devel installed for reasons other than rapidfuxx will still get the files, but the assumption here is that users who install -devel packages intent to /generally/ build stuff.)

Is that a good suggestion? And if so, should it be a general recommendation for such cases?

No. To me that's an ugly hack.

Ralf

V Fri, Feb 17, 2023 at 03:38:45PM +0100, Miro Hrončok napsal(a):

Hello Pythonistats and packaging folks.

Tomáš (CCed) approached me today with an interesting question. A Python package he is packaging into RPM (python3-rapidfuzz) installs some development files (.h and .pxd).

Tomáš queried upstream about those files to figure out if they should be installed or if they are only needed to build the package itself. Upstream responded:

...

rapidfuzz.h and __init__.pxd provide a capi for rapidfuzz, which allows users to write their own similarity metrics in C/C++/Cython, which can be called by rapidfuzz in a more performant way through this C-API. For this reason the header file should be part of the installation as well.

OK, we want to ship them. Our packaging guidelines however say:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages

...

Specifically, -devel packages must be used to contain files which are intended solely for development or needed only at build-time. This is done to minimize the install footprint for users. There are some types of files which almost always belong in a -devel package:

• Header files...

So from our guidelines perspective, the files would go to python3-rapidfuzz-devel. The way we packaged Python in 201x, this would be the end of it.

However, in this decade with automatic Python BuildRequires, we could easily end up in this situation:

1. a Python package lists rapidfuzz as a build requirement
2. %pyproject_buildrequires generates a dependency on python3dist(rapidfuzz)
3. only python3-rapidfuzz is pulled
4. %build wants to use rapidfuzz.h
5. packager needs to manually BuildRequire python3-rapidfuzz-devel

To avoid (5), my suggestion was to add the following requirement to python3-rapidfuzz:

Requires: (python3-rapidfuzz-devel%{?_isa} = %{?epoch:%{epoch}:}%{version}-%{release} if python3-devel)

That way, application packages that pull in pytohn3-rapidfuzz as a runtime dependency won't get it (we are minimizing the install footprint for users), but users who build stuff (including RPM packages) will get it (we make automatically generated dependencies work as intended).

(Of course, users who have python3-devel installed for reasons other than rapidfuxx will still get the files, but the assumption here is that users who install -devel packages intent to /generally/ build stuff.)

Is that a good suggestion? And if so, should it be a general recommendation for such cases?

Originally I wrote a long reply and I found out that I'm in two minds and deleted it.

Now thinking more on it, I conclude that the only effect of the proposal is to make Fedora packaging compatible with upstream (installing Python modules with pip, automatic generation of Fedora packages) at the expense of forcing users to install the devel subpackage.

The reasoning is this: If the devel package is small (size- and dependency-wise), it's content could be merged into a main package and nobody would notice. If the devel package is large, then it would matter, especially to people who do not want to install it. And that's exactly the situation where a downstream's packaging differing from upstream is the raison d'être for existence of the downstream itself.

Try to answer why we do not put Requires: (openssl-devel if gcc) to openssl-libs.

Therefore I recommend not to require adding the dependency. Instea, the packager should evaluate whether the feature is essential or optional, and do not split it from the main package, or split it without conditions.

-- Petr