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

[Fab Stz]

Hello James,

The remaining php-* packages were accepted.

Would you have a look at "kalkun" now?

Repo is currently located here:
https://salsa.debian.org/bastif/kalkun

Should I move it to https://salsa.debian.org/php-team/pear ?

Regards
Fab

Le samedi 2 septembre 2023, 17:36:53 CEST James Valleroy a écrit :
> 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.