Hi David, upstream author here. ZF2 was already a thing (and stable) once we started developing Icinga Web 2. We consciously opted for ZF1 at that time. In my believes ZF2 is over-engineered and slow. Some of the changes going on for ZF3 are telling me that we were not completely wrong ;)
We are not the only PHP project that decided to take this path. We wrapped ZF1 with our framework, tried to follow ZF1 design principles in a more modern way. ZF1 is still alive, supported, ships security fixes and has never been declared EOL. ZF2 and ZF3 are not successors but completely different frameworks with different architectures and design goals. Icinga will never move to ZF2. In case ZF1 will once be declared EOL we will probably prefer to replace the functionality we use with our own code before moving to ZF3. We might change our opinion on this. ZF3 feels like an attempt to find a compromise between becoming a framework again (IMO they lost the frame in ZF2) while not breaking ZF2 components. Sounds promising, but probably comes too late for us. As a PHP project it is hard enough to build software based on libraries shipped with various distributions. We support Debian, RHEL, SLES and of course all kind of variants in various versions. It would be easier for us to be allowed to ship our own stripped down php-icinga-vendor-zf1 package. Could you give me any hint how this could be accomplished and whether or not it fits Debian's packaging guidelines for PHP projects? Let me give you just one concrete example, where the current way of packaging really, really hurts us: one of the most important upcoming Icinga Web 2 modules (publicly available, neither tagged nor packaged yet) works with binary data (mostly checksums) in databases: https://github.com/Icinga/icingaweb2-module-director Now ZF1 broke binary data in a security fix erroneously applied to all adapters while required only for two of them. Not a big thing, we plan to blacklist the affected versions once we tag the director module stable. However, that wouldn't work for Jessie. Jessie is lagging behind 8 patch versions - it ships ZF 1.12.9 from 2014. What we didn't grasp until very recently was that 1.12.9+dfsg-2+deb8u4 backported that security fix from 1.12.16. It's perfectly fine that a stable Debian release stays with a specific minor release. But I do not understand why patch versions are not shipped as upstream provides them. Following this policy the fix for the mentioned issue (https://github.com/zendframework/zf1/issues/655) will not make it into Jessie as it will definitively not be flagged as a security issue once released with 1.12.18 (pull request is still pending). The result of this are databases with irreversibly broken binary data. And as an upstream author I have no real chance to protect my users from this as Zend_Version in Jessie is basically lying to me. Please forgive me this slight OT drift, and please do not get me wrong on this. I absolutely appreciate the effort you are spending on shipping ZF with Debian. I picked this example to show the problems we are facing and to explain why we would really love to ship "vendored vendor packages". Having an php-Icinga-vendor-zf1 package putting files into /usr/share/icingaweb2/library/vendor/Zend would be great for us. And I guess as you are already planning to not ship ZF1 with Stretch this should be fine also policy-wise. Regards, Thomas Gelf
