On Fri, Feb 17, 2023 at 10:36 AM Ralf Corsépius <rc040203@xxxxxxxxxx> 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.
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/packaging@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
