Package: php-pear Version: 1:1.10.18+submodules+notgz-1 Severity: wishlist 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
signature.asc
Description: PGP signature
