[pkg-php-pear] Remaining packages looking for sponsorship

[James Valleroy]

On 9/1/23 2:41 PM, Fab Stz wrote:
> libphonenumber-for-php (upstream) is a php wrapper for google's
> libphonenumber.
> Upstream releases a new version as soon as google updates the metadata of
> libphonenumber. This is usually every 2 weeks.
> 
> The idea with the updater script/package is like `update-pciids` for example.
> It will take the metadata of the latest libphonenumber-for-php version and
> replace the current metadata stored in /var/lib/php-giggsey-libphonenumber

Yes it looks like update-pciids does something similar, it replaces a 
file installed by pci.ids package.

> Waiting a new Debian stable release to get updated phonenumber metadata seems
> very long.

There are other options like updating the version in stable, and 
providing more frequent updates through stable-updates. For example, see 
the tzdata package in bullseye and bullseye-updates.

> It seems update-pciids stores data to /usr/share/misc/pci.ids
> What would be the right location for the metadata of php-giggsey-
> libphonenumber then (instead of /var/lib/package) ?

Perhaps /var/lib/package is the right location then. I wonder if there's 
a way to install the packaged files in location A, and the downloaded 
files in location B, and have a configuration file, or a symlink, to 
decide which one is used?

> Concerning the separate package, it was mainly to have a distinction between
> what is strictly from upstream (php-giggsey-libphonenumber) and what is a
> helper script provided only on Debian (php-giggsey-libphonenumber-updater).

I don't see a need for a separate binary package in this case. It seems 
fine to include an additional utility script in the main package.

I am also having some security concerns about this approach. It's easy 
to imagine that upstream's repository could be compromised, and we end 
up installing PHP files that have malicious code instead of just data. 
Perhaps the script should display a warning that it will download files 
provide by upstream, and that they are not supported by Debian Security 
Team.