BTW, these were just retired the other day, so shouldn't need a re-review.

Note that all of them have broken build dependencies, so they will not build.

yeah. ;( I guess hold off on this for a bit until I get cycles to look at how it can be fixed. ;(

Okay so as per the comments, it seems like we will do unretirement of these packages later on, correct?

ok, so I looked at this a little bit today.

@mooninite Can we just bundle the vendored iuggio/statsd-php-client in mediawiki ? Or do we still somehow need symfony even if we do that?

Perhaps @remi has some advice here? Whats the best way to keep mediawiki happy here? will using that bundled/vendored iuggio/statsd-php-client work?

Sorry, @kevin, I will look at this when I have time.

The mediawiki package is probably not the best place for bundling. The symfony dependency is required in the 'php-liuggio-statsd-php-client' package and it would best be bundled in there.

https://koji.fedoraproject.org/koji/taskinfo?taskID=122633140

No match for argument: php-composer(symfony/class-loader)

Sadly, it seems nobody cares about PHP in Fedora, and I'm the only one to maintain hundreds of packages (ex: reviews are stalled for months...)

PHP applications now heavily rely on composer for dependencies.

Nobody will never use any system PHP libraries

I think it make more sense to concentrate my time on PHP extensions (need build)

So I mostly choose to let broken PHP libraries die (ex symfony 3 which is outdated, versions 4, 5 and 6 exists)

Simple way is to bundle everything.

• Case 1: upstream provides a full tarball with all dependencies => use it

ex: phpMyAdmin, Wordpress, roundcubemail

I also use a simple script that provides a list of the bundled libraries ordered by SPDX License.

• Case 2: upstream provides minimal tarball with composer.json => generate the full tarball

ex: composer, php-cs-fixer

A simple composer install does it, see above packages as example.

I try to maintain some app the old way (ex phpunit*) but phpunit11 is waiting for review for >6 months... so... don't know if it worth the work :(

Yeah, in this case mediawiki package does include iuggio/statsd-php-client, we just currently delete it and try and use the seperate fedora package ( php-liuggio-statsd-php-client. ). That package in turn wants these 3 retired packages.

I think if we don't delete it in mediawiki and just use the bundled one there it should work and we can drop the dep on php-liuggio-statsd-php-client and not worry about these being retired.

But I might be missing something.

@kevin better/simpler to keep the "vendor" directory unchanged (see phpMyadmin, especially the phpMyAdmin-bundled.php script run during %prep)

It seems unbundling was not really done properly (ex: vendor/symfony is there with some others)

The proper way was to remove the "vendor" directory and create an autoloader including all the dependencies autoloaders (from composer.json). Mixing system and bundled libraries seem a bit ugly.

Also notice that php-liuggio-statsd-php-client is FTBFS because of missing build dependency

You can probably fix it by dropping this BR and removing tests using symfony or monolog.
(perhaps drop the test suite)

Notice: instead of creating a symlink to /usr/share/php/Liuggio you should include /usr/share/php/Liuggio/StatsdClient/autoload.php in your autoloader.

BTW, again, it will be simpler to use the full vendor unchanged.

Hey, @kevin do you think we can close this ticket for now? And open the unretirement request when packages are ready and reviewed?

Sure. Hopefully we can sort things out before f40 goes eol. ;(