On Fri, Feb 17, 2023 at 10:36 AM Ralf Corsépius <rc040203(a)freenet.de> wrote:
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
May I agree? Demanding that, on a package by package basis, people add
a new requirement not reported by "pip install" is going to stink. It
occured with the python3-ldb-devel package, which has been playing
peek-a-boo in the libldb srpms. And I'm afraid that generating so many
new devel packages will encourage RHEL to play peek-a-boo with those
devel packages, just as they did for lmdb-devel. They built and use it
for compiling Samba, but hid it away in a non-standard "devel" channel
and caused interesting chaos for people like trying to build Samba
updates. Refactoring deployments is often an architecturally exciting
but non-helpful change.