Hi Alex, you can depend on libphp-embed and then prepare the substvars like this:
echo "libphp-embed:Depends=libphp$(phpquery -V | head -1)-embed“ > debian/uwsgi-plugin-php.substvars and then in debian/control you would use Depends: ${libphp-embed:Depends} instead of Depends: libphp-embed Alternatively You can of course walk through the full list returned by phpquery -V and build a separate version of the plugin for each available PHP version, but you would still have to prepare the substvars. Cheers, Ondrej -- Ondřej Surý ond...@sury.org > On 5 Jun 2020, at 16:02, Alexandre Rossi <n...@zincube.net> wrote: > >>> I do not have much experience with shared object libraries, but as >>> libphp7.3.so and libphp7.4.so declare the same soname libphp7.so, I could >>> not find a way for uwsgi-plugin-php to explicitely reference libphp7.4.so : >>> passing -lphp7.4 to the linker still goes back to linking to libphp7.so . >> >> Don't we already do that by depending on PHP ABI? >> >> If phpapi-20190902 is provided by multiple binary incompatible package >> releases, then it seems to me that there is a bug in PHP packaging! >> >> If you agree (i.e. if I haven't again misunderstood the issue) then I >> think this bug should be reassigned to src:php7.4 as we already follow >> their mechanism for locking in on a specific ABI. > > I agree: > - uwsgi-plugin-php depends on libphp-embed, phpapi-20190902 > - in bullseye, libphp-embed pulls libphp7.3-embed and phpapi-20190902 > pulls php7.4-cli > - libphp7.so point to libphp7.3.so > - uwsgi-plugin-php (built against 7.4) segfaults... > > I could not find any way to express that uwsgi-plugin-php depends > on libphp7.4.so and not libphp7.3-embed, other than depending on > libphp7.4-embed explicitely. > > What do the php folks think? > > Alex >
signature.asc
Description: Message signed with OpenPGP