Symfony 2.3.34, composer update broken by security-core

[larspohlmann]

Hello community,

there seems to be a problem with the composer update for Symfony 2.3.
This has been happening for the past ca. 3 days.

/usr/bin/php composer.phar update --no-dev --verbose --prefer-dist --optimize-autoloader --no-progress'
  * Updating dependencies
  * Analyzed 6234 packages to resolve dependencies
  * Analyzed 182882 rules to resolve dependencies
  * - Installing doctrine/cache (v1.5.1)
  * Loading from cache
  * Extracting archive
  * - Installing doctrine/inflector (v1.1.0)
  * Loading from cache
  * Extracting archive
  * - Installing psr/log (1.0.0)
  * Loading from cache
  * Extracting archive
  * - Installing twig/twig (v1.23.1)
  * Loading from cache
  * Extracting archive
  * - Installing doctrine/lexer (v1.0.1)
  * Loading from cache
  * Extracting archive
  * - Installing doctrine/annotations (v1.2.7)
  * Loading from cache
  * Extracting archive
  * - Installing doctrine/collections (v1.3.0)
  * Loading from cache
  * Extracting archive
  * - Installing doctrine/common (v2.4.3)
  * Loading from cache
  * Extracting archive
  * - Installing symfony/symfony (v2.3.34)
  * Downloading
  * Extracting archive
  * - Installing symfony/security-core (v2.7.6)
  * Loading from cache
  * Extracting archive
  * - Installing symfony/security-acl (v2.7.6)
  * Loading from cache
...

Later in the process

Generating optimized autoload files
  * Warning: Ambiguous class resolution, 
"Symfony\Component\Security\Core\Validator\Constraints\UserPasswordValidator" was found in both
 "/var/www/payment/releases/20151109092431/vendor/symfony/security-core/Validator/Constraints/UserPasswordValidator.php" 
and 
"/var/www/payment/releases/20151109092431/vendor/symfony/symfony/src/Symfony/Component/Security/Core/Validator/Constraints/UserPasswordValidator.php", 
the first will be used.

Followed by many similar warnings...

Part of my composer.json:

"require": {
    "php": ">=5.3.3",
        "symfony/symfony": "v2.3.34",
        "doctrine/orm": ">2.2.3,<2.4-dev",
        "doctrine/doctrine-bundle": "1.4.0",
        "twig/extensions": "1.2.0",
        "symfony/assetic-bundle": "2.6.1",
        "symfony/swiftmailer-bundle": "2.3.8",
        "symfony/monolog-bundle": "2.7.1",   
        "graylog2/gelf-php": "1.2.3",
        "sensio/distribution-bundle": "3.0.21",
        "sensio/framework-extra-bundle": "3.0.7",
        "sensio/generator-bundle": "2.4.0",
    "jms/security-extra-bundle": "1.5.1",
        "jms/di-extra-bundle": "1.5.0",
        "jms/serializer-bundle": "0.13.0",
    "aequasi/memcached-bundle": "1.5.6",
    "guzzlehttp/guzzle": "5.2.0",
    "authorizenet/authorizenet": "~1.8"
    },

[lxg]

I can confirm this for the 2.3.x series.

[linaori]

Somehow you're getting:

• symfony/symfony (v2.3.34)
• symfony/security-core (v2.7.6)
• symfony/security-acl (v2.7.6)

This is wrong because 2.3 is supposed to replace those. In 2.3 the security-acl did not exist yet thus shouldn't be installed, not sure about security-core. Could it be that a vendor package depends on these?

To get some more information, can you run composer depends symfony/security-core and symfony/security-acl?

[lxg]

lxg@tp $ composer depends symfony/security-core
symfony/security-acl requires symfony/security-core (~2.4)

lxg@tp $ composer depends symfony/security-acl
doctrine/doctrine-cache-bundle requires symfony/security-acl (~2.3|~3.0)

I also should note that we upgrade our 2.3.x installs by copying the require section from the composer.json file: https://github.com/symfony/symfony-standard/blob/2.3/composer.json#L10-L21

[linaori]

@lxg you can probably fix this in your case by setting the dependency to "symfony/symfony": "2.3.*".

[larspohlmann]

I have the same output as @lxg .

[nicolas-grekas]

Shouldn't symfony/security-acl be fixed to require symfony/security-core ~2.3|~3.0?

[xabbuh]

I guess this will be solved with #16144 is part of the next release because then there is no need for a separate symfony/security-acl installation.

[lxg]

@iltar "symfony/symfony": "2.3.*" is exactly the entry I have, as per https://github.com/symfony/symfony-standard/blob/2.3/composer.json#L11 and that doesn’t work unfortunately.

@xabbuh Do you have a rough estimate when this will be released?

[xabbuh]

@lxg Unfortunately no, it's up to @fabpot to decide.

[larspohlmann]

IMO, this should have a high priority as it breaks automated deployment of production environments. At least for us...

[linaori]

@larspohlmann it shouldn't break deployment, only updates

[larspohlmann]

We use jenkins with capifony for distributed deployment, which relies on "composer update". So, in our case, it sadly does.

[linaori]

@larspohlmann you should never run composer update when deploying. The correct command is install. This will install the dependencies in your lock file instead of always the newest.

[larspohlmann]

Thanks for the advice. This might help us to avoid more trouble in the future.

[nicolas-grekas]

And, you should also commit your composer.lock file!

[lxg]

@iltar For us, it does break builds with composer install. A plain composer install works though. What fails is composer install --optimize-autoloader (with or without --no-dev).

[fredpo]

How is this not a high priority if this breaks symfony running composer update with "symfony/symfony": "2.3.*" ? This isn't exactly an edge case and affects thousands of deployments. How does this even pass testing?

[xabbuh]

@fredpo You simply should never use composer update when deploying. How would you ensure that the application you are deploying is the same you used in your development and testing environments? Simply version the composer.lock file of your application and run composer install instead.

[fredpo]

@xabbuh I've never stated I deployed with composer update, I've stated that running composer update breaks an existing deployment, something that has already been installed, deployed. This issue essentially makes 2.3.34 a broken, unusable update for many unless one removes symfony/security-core (v2.7.6) and symfony/security-acl (v2.7.6) I don't understand why people are redirecting this to a composer install vs composer update debate when the issue is clear, this update is broken.

[xabbuh]

@fredpo Of course this is a bug. But it is not urgent as you notice it in your development environment, update your dependencies and commit the updated lock file. So nothing breaks in the deployed applications.

[derrabus]

A workaround would be to add this requirement to the "require" block of your project's composer.json:

"doctrine/doctrine-cache-bundle": "<1.2"

This is of course not the solution, but it keeps your composer update working. Once Symfony 2.3.35 has been released, you can (and probably should) remove that line again.

[lxg]

@derrabus Thanks, this looks like a valid a workaround; at least our build process does no longer produce errors/warnings.

[xabbuh]

closing here as 2.3.35 was released today

[lxg]

@xabbuh thanks! Confirming that 2.3.35 does no longer break our builds.