Don't restrict symfony/symfony packages

[nicolas-grekas]

Will allow "unpack" to replace the wildcard by what's in extra.symfony.require also.
See symfony/flex#443
This should be the best practice.

[teohhanhui]

I honestly do not understand why the * version constraint is a "best practice". And we don't have extra.symfony.require set here.

[nicolas-grekas]

Because that's a pack - and packs should not impose constraints on your deps.

[nicolas-grekas]

we don't have extra.symfony.require set here.

it's not "here", but in a flex-enabled app - which packs are built for.

[teohhanhui]

I still disagree. The extra.symfony.require in the app could be anything, and we cannot guarantee that things would actually work if we do not enforce our version constraints. (Of course, if the user does not use this pack, they might still install incompatible versions of the these optional dependencies.) These are the supported versions of Symfony components that we run our CI builds with.

[teohhanhui]

I think symfony/flex#443 is brilliant, but it still does not sufficiently address the concern I've raised before. This PR made me realize that.

[nicolas-grekas]

That's not the responsibility of a pack (guarantee that things would actually work).

[teohhanhui]

This is how I think about it: a collection of dependencies that we've put together. And to me that also means the dependencies are in selected versions that work together.

But I see your point. (Especially because the type is symfony-pack, so I'd respect the semantics you've defined.)

[dunglas]

Thanks @nicolas-grekas