icinga-php-library 0.11.0 includes dependencies also provided by icinga-php-thirdparty

[sebastic]

icinga-php-library 0.11.0 added a bunch of vendored dependencies (installed in /usr/share/icinga-php/ipl/vendor), many of these are also provided by the icinga-php-thirdparty package (installed in /usr/share/icinga-php/vendor/vendor):

• evenement/evenement
• guzzlehttp/psr7
• paragonie/random_compat
• psr/http-message
• ralouphie/getallheaders
• ramsey/uuid
• react/event-loop
• react/promise
• symfony/polyfill-ctype

Some are only provided by icinga-php-library:

• doctrine/collections
• doctrine/deprecations
• dragonmantank/cron-expression
• fortawesome/font-awesome
• psr/log
• simshaun/recurr
• webmozart/assert

Shouldn't the thirdparty dependencies of icinga-php-library be provided by icinga-php-thirdparty, or will icinga-php-thirdparty only provide the thirdparty dependencies of icingaweb2 and icingadb-web?

Issues like PHP 8.2 support now need to be fixed in both copies of guzzlehttp/psr7 for example: Icinga/icingaweb2#4918 (comment).

[nilmerg]

Hi,

we are aware of this (as can be seen in #22), but this is due to architectural limitations in how libraries in Icinga Web work.

Users shouldn't worry about this. PHP 8.2 support doesn't need to be fixed either, at least not by us, we just upgrade to new versions of those dependencies. And whether we do this only in icinga-php-library, only in icinga-php-thirdparty or in both, is in no way relevant to this question or in any way problematic.

If you want to notify us about allegedly new PHP 8.2 related issues, please do so in the mentioned issue above, like you already did. No need to cross post anything here.

Thank you.

[sebastic]

Users shouldn't worry about this. PHP 8.2 support doesn't need to be fixed either, at least not by us, we just upgrade to new versions of those dependencies. And whether we do this only in icinga-php-library, only in icinga-php-thirdparty or in both, is in no way relevant to this question or in any way problematic.

Users will complain about the deprecation warnings like they did for the skip_validation dynamic property: Icinga/ipl-sql#69

You still haven't upgraded to versions of the dependencies which fix the PHP 8.2 compatibility.

How much does Icinga GmbH need to be paid to take PHP 8.2 support seriously?

If you want to notify us about allegedly new PHP 8.2 related issues, please do so in the mentioned issue above, like you already did. No need to cross post anything here.

This issue is to clarify whether the duplicated dependencies will move to icinga-php-thirdparty or something else. You haven't really answered that question, nor does #22 do that.

Thanks for showing that Icinga upstream is just as unpleasant to work with as Nagios upstream.

[nilmerg]

The user reported it because he's using Debian Bookworm. This is still in testing and even hasn't a release date. We don't bother with fixes for yet unreleased and by us unsupported distributions. If you test Icinga Web and its parts on such a platform, you are free to notify us about your results. We welcome this of course.

But we don't hurry anything nor do we upgrade or fix parts that are incompatible with a new PHP version. We prepare such a change carefully and release support once it's ready and required. (Required = A distribution we support has a stable release) If you are able, you can of course help us with that. 😄 No one is paying us for that, so it needs time and we have to perform it in parallel to other things.

[sebastic]

You are very bad at answering questions.

I know that you (Icinga GmbH) don't care about unreleased distributions, but I assume that if you have a paying customer that does care, you can be made to care.

Hence my question: How much does Icinga GmbH need to be paid to take PHP 8.2 support seriously?

If the price for such a contract is reasonable and within my means, I'm willing to pay that to make my life as maintainer of the Icinga packages in Debian easier.

Alternatively, Icinga GmbH can pay me for my time spent on creating the PHP 8.2 patches for the Debian packages and the CLA shenanigans to let me upstream those changes.

[nilmerg]

I'm not going to discuss this further with such an attitude of yours.

We don't pay you, it's open-source. If you want to pay us, request an offer here.