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

[Fab Stz]

With the updater script, there is a possibility that the latest upstream 
version contains changes to the PHP code in addition to metadata changes. I 
can imagine that in some cases, the change in PHP code could lead to changes 
in the metadata structure. In such a case, the newly downloaded metadata might 
not work anymore with the actually installed PHP code. Your suggestion to let 
the user choose wether he wants the Debian package metadata or upstream 
metadata would permit to manage this.

Actually the script could work this way:
- have the debian package metadata in 
/var/lib/php-giggsey-libphonenumber/available/debian-$VERSION
- have additional metadata downloaded from upstream in 
/var/lib/php-giggsey-libphonenumber/available/upstream-$VERSION
- At the end of the updater the user would be asked which one to use. If he 
selects an "upstream" version, he would be warned of the security risk & that 
latest metadata might not work anymore with PHP code and would have to confirm 
his choise. Then the updater would create the symlink /var/lib/php-giggsey-
libphonenumber/enabled (which would be the location where the PHP code looks 
for the metadata)

When a new version of the package is installed, the metadata stored in /var/
lib/php-giggsey-libphonenumber/available/upstream-* would be deleted.

Concerning the stable/stable-proposed-updates I'm not sure I want to commit to 
frequent updates (everytime metadata changes), especially if there are only 
few users. Maybe we could say that the package could be updated this way when 
the latest upstream metadata structure is not compatible anymore with the PHP 
code in stable. But in that case, it would mean that in proposed-updates there 
will not only be metadata changes, but also PHP code changes.
BTW, such changes seem very rare if I look at the release history (yearly?).

Ok, to add the updater script to the main package and remove the "updater" 
binary package.

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.