Travis exited with a segfault on PHP 5.3.3 only...?!?

@mpdude yes, it's not your fault though. The problem exist for some time now (see#7754).

Thanks for working on smaller PRs. That's much appreciated, and it definitely makes things easier.

Unfortunately, this one cannot be merged as it would introduce a hard dependency between HttpKernel and Config for instance, which we must avoid as some projects using Symfony do not want to depend on Config (like Drupal for instance).

As a rule of thumb, code duplication in Symfony exists for a reason, so refactoring like this one will almost always be rejected.

I was aware of that need of f. e. Drupal, but somehow failed to see the new dep here. Sorry.

Better now?

What about movingCacheFileUtils::dumpInFile() to the Filsystem component class instead? And remove the other two methods that are not used anyway.

Regarding the Filesystem component: Good idea and better place, but would be a change dependency-wise? Component/Config then would need Component/Filesystem. Bundle/FrameworkBundle/* probably don't care...

Adding the Filesystem component as a dep to Config is not a problem.

For the method name in Filesystem, we should probably come up with a better name thandumpInFile.dumpFile orstoreFile should be enough, no?

Great, yes, will do.

Except for the getMetaFile method, everything else looks good to me. Can you also add a note in the Filesystem CHANGELOG?

Adding the getMetaFile() was a reflex action as the meta file name is built in two different methods, though I forgot one of the places when picking from#7230. Shall I make it private?

Just to be sure, don't we have to do anything about the new Config -> Filesystem dep? Add it to the Config component composer.json maybe?

You are right, you need to add the filesystem component as a required dep for the config component.

Nervermind, I'm doing to do it after the merge.

Thanks, learned a lot already today.

The next picks will probably become much more interesting than that :-)