[Pkg-nagios-devel] Bug#814143: Depends on zendframework, but zendframework is going away

[Thomas Gelf]

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