I'd suspect most people are using composer 2 anyway these days, but this would mean some potential breakages

This will affect Ubuntu 18.04 (LTS), Ubuntu 20.04 (LTS) and CentOS 8. They are popular distros offered by web hosting and VPS services.

The Composer 2 requirement is causing problems for us at Crypto++ (www.cryptopp.com). We run some static pages and a wiki. We were not able to migrate to MW 1.39 because of doctrine/dbal . We cannot migrate to Ubuntu 22.04 at the moment because our web host only provides Ubuntu 20.04, Ubuntu 18.04, CentOS 8, CentOS 7, Debian 10, Debian 9, OpenSuse Leap 15. Also see https://www.ionos.com/servers/vps .

... only for installing non require-dev libraries; I think?

composer install --no-dev tries to bring doctrine/dbal in.

As a side note, https://www.mediawiki.org/wiki/Download#System_Requirements should probably detail the Composer 2 requirement. I tried to perform the migration from MW 1.38.5 to MW 1.39 this weekend. It failed at the composer step. I was able to recover quickly because our upgrade procedure include making a copy of the existing MW installation. Others may not be so lucky, especially if they have to restore from backup.

It's should be trivial to use non packaged composer, though. You can grab a phar from their website, and then use php /path/to/composer.phar <command>... You don't have to use the installed one in $PATH

composer 1.x has been out of security support for 2 years.

In T316556#8490726, @Noloader wrote:

... only for installing non require-dev libraries; I think?

composer install --no-dev tries to bring doctrine/dbal in.

Not quite. It'll will include it in composer.lock but it doesn't install it to disk.

It's should be trivial to use non packaged composer, though. You can grab a phar from their website...

So this is a problem for us. We only want managed software on the web server. Currently Ubuntu manages the software, reviews and tests the software, provides bug fixes and security updates, etc. It does not take much work on our part. We merely run apt update && apt upgrade daily and the machine stays up to date.

We don't want unmanaged software on the server. We don't want to manage it. It is too much work. In fact, we are all C/C++/ObjectiveC people. We could not audit Composer even if we had to. We don't have the expertise to do it.

We made an exception for Mediawiki years ago. It was worth the risk, but it is a lot of work at times. We would prefer someone else perform the work (like a distro), but we want the features so we take on the responsibility.

And from what I've seen, Composer is an insecure cesspool. It should not be required on a production server to begin with. The tarball should have everything needed to run the software.

In T316556#8490731, @Noloader wrote:

The tarball should have everything needed to run the software.

It does, for MediaWiki and bundled extensions in the tarball.

In T316556#8490731, @Noloader wrote:

Currently Ubuntu manages the software, reviews and tests the software, provides bug fixes and security updates, etc.

Getting slightly off topic, but Ubuntu's security support only applies to packages in the "main" component, not "universe" (see https://wiki.ubuntu.com/SecurityTeam/FAQ). PHP itself is part of main, but "composer" is part of universe, so it doesn't get security support.

And if you don't use the tarball, you can check out the corresponding REL1_XX branch of the mediawiki/vendor Git repo, which has all the composer dependencies needed to run MediaWiki core plus bundled extensions/skins.