+1

+1

+1

Aren't there still multiarch libraries that need php at build time?
For example, libvpx build-requires php-cli.

Aren't there still multiarch libraries that need php at build time?
For example, libvpx build-requires php-cli.

I don't see anything in libvpx sources code using PHP
Dropping this BuildRequires seems OK (local test build)

P.S. https://src.fedoraproject.org/rpms/libvpx/pull-request/7

OK, that was just one example -- have you looked for others? Something like:

$ dnf repoquery --release rawhide '--disablerepo=*' '--enablerepo=fedora-source' --arch=src \
    --whatrequires=php{,-cli,-devel} -q | grep -v ^php
composer-0:2.7.2-1.fc41.src
flamegraph-0:1.0-17.20231107gitcd9ee4c.fc40.src
libguestfs-1:1.52.0-7.fc40.src
libkolabxml-0:1.2.0-22.fc40.src
libvpx-0:1.14.0-1.fc40.src
libvpx8-0:1.13.1-1.fc40.src
lsp-plugins-0:1.2.15-1.fc41.src
mapserver-0:8.0.1-13.fc40.src
mediawiki-0:1.40.0-3.fc40.src
mlt-0:7.22.0-4.fc40.src
owfs-0:3.2p4-6.fc40.src
roundcubemail-0:1.6.6-2.fc40.src
scip-0:9.0.0-1.fc41.src
soplex-0:7.0.0-1.fc41.src
swig-0:4.2.1-2.fc41.src
uwsgi-0:2.0.24-1.fc40.src
wordpress-0:6.4.3-1.fc40.src

Some of those are noarch, which is fine, and some like libguestfs already dropped i686 themselves. swig is far-reaching, but looks like it only uses php for tests.

swig is used to generate library bindings, php support is optional, and already conditional (so easy to disable on 32-bit)

some libraries provide php bindings (mlt, libkolabxml...), so the subpackage may be disabled.

For uwsgi, the php plugin is already conditional and may be disabled on 32-bit

To be discussed at mondays meeting.

@remi if you could make it that would be great.

This was discussed during the meeting, where we realized that the ticket was already approved here according to the policy.

APPROVED (+3, 0, 0)