You probably don't need bundle dependencies
Update: When you're done reading this, make sure to read Marc's response, and my response to Marc.
I was reading up on Twitter, regarding what's missing in Symfony, and one of the things suggested was bundle dependencies. Turns out that Marc Morera has actually written an interface for handling bundle dependencies.
I'm not saying this is a bad thing. I am however saying that in 90% of the situations where you think that using bundle dependencies would be neat, you're not using the bundle system the way I feel it is best used.
What is a bundle
Let's begin by examining what a bundle is. Back in ye olden days, we used to put all our code in a bundle, or better yet, many bundles. The more bundles the merrier, but everything was in a bundle.
Often we had like 20 bundles for discrete parts of our application, but they were all inter-dependent. That wasn't ideal. Sure, it provided some structure, but it was a big inter-dependent mess. I mean it's not like you could remove one of the bundles and use them in another project anyway, and it's not like you could have one team per bundle in a large organization, because everything was so inter-dependent. So we learned to not use Bundles as organization tools, and instead use sub-namespaces better. Now we had one big bundle with everything in it, with mostly only vendor depencies.
This was still not great. We had written all of this awesome code, but it was often tightly coupled to Symfony. Even it it wasn't tightly coupled, it was still in a bundle package. If we wanted to use that code in something like a Silex app, we were shit out of luck. So we fixed that.
Instead of having all our code in bundles, we split it into bundles and libraries. The library was a reusable piece of software, with few dependencies, and the bundle integrates that piece of software into the Symfony framework. If we want to use it with Silex, we no longer had to ship it with a bunch of non-used Symfony cruft.
So, we're reaching a definition: A bundle is (hopefully thin) layer that integrates a library into Symfony.
Bundle dependencies
With this definition, it becomes increasingly clear: If you're doing a thin integration layer, you probably don't want it to have dependencies on other bundles.
Your library probably has a lot of dependencies (on other libraries). That's fine, probably (but that's a different blog post). But your bundle has a very clear purpose, it integrates your library and Symfony. Thus it ideally only has two dependencies: your library and Symfony.
Aside from the philosophical issue, bundle dependencies are usually messy in practice. You assume a lot of things about the state of the dependency injection container. This makes your application fragile.
Configuring your library dependencies explicitly in the bundle configuration is usually more robust. In the spirit of DX, you may also want to have optional dependencies on bundles, i.e. "if this bundle exists, pre-configure my bundle with these settings". That's fine. I would hardly call that a dependency, since it's optional.
Now, I'm not going to be arguing in terms of absolutes here. Sometimes a thin integration layer doesn't work out, and you actually need to have bundle dependencies, but before you do, you should ask yourself:
Is it really my bundle that has this dependency, or is it actually my library?