tl;dr: what kind of backward compatibility do we need to maintain?

Hi Ondřej and all,

While upgrading php-pear to its latest upstream version, I had to fight
with git submodules. With the current global move from PEAR to Composer
to distribute PHP code, upstreams follow the usual flow or sickness of
adding .gitattributes files to exclude tests and other valuable pieces
of code from their source tarball. That messed our usual workflow in the
PHP PEAR (and Composer) Maintainers team, but we managed to find our way
around it [1]. On the other hand, it messes a lot with the current
packaging workflow of php-pear, that needs to remove .gitattributes
files from of its git submodules.

I’d like to update the packaging workflow of this package, maybe using
multiple upstream tarballs as allowed with the 3.0 (quilt) source
format, or maybe more simply with a package split of its dependencies (I
haven’t looked at the specifics yet).

I’m well aware of the need to **not** build-depend on pkg-php-tools,
since that would introduce a dependency loop, but are there any other
requirements? Ondřej, I know you put a lot of work to maintain the
PHP ecosystem on multiple Debian (and more) release versions, do you
need to have php-pear around too? If so, what is the older Debian
release you need to support? I don’t want to introduce backward
incompatible changes that would make your life harder.

  1: https://wiki.debian.org/Teams/DebianPHPGroup/Composer#Upstream_handling

Regards,

taffit

Hi David,

generally speaking, php-pear is only useful as dependencies to other Debian packages, so it only needs to stay compatible with the one single release matching whatever we just have.

Packaging php-pear was always absolute PITA, so if you find a way to do it differently, I would be delighted!

Ondrej
--
Ondřej Surý (He/Him)

A gentle nudge is always appreciated if I take a little longer to reply.