How should I publish my projects as NuGet packages considering dependencies between them?

The problem:

I have a toolkit consisting of many packages, the source is just one big solution containing the package sources, unit tests and demos.

Each package project needs to be a separate NuGet package, but some projects depend on other projects.

In projects, I have local project dependencies, pointing to the project files.

Lets say I have a root package A. B, C, and D depends on A. And let's say E depends on B.

Let's say the dependency tree looks like this:

- A  |-B-E  |-C  |-D

What will happen when I publish packages A, B, C, D, E?

Will package E be just project E compiled with the dependency on packagesB (where B depending on packageA) - or the package E would have no dependencies and A and Bprojects built in?

Please note the difference between project reference and package reference!

In my solution, I have only project references. What I want in my resulting packages are package references. My B.csproj should depend on A.csproj but my B.nupkg should depend on A.nupkg.

What I want to achieve is being able to upgrade individual packages without breaking the rest of them. Of course I mean non-breaking changes, like adding a class or method to A, fixing a bug in A without changing the API.

Let's say I find a bug in package A affecting all the other packages. I want just fix the package A and publish it as a new version. Then, the project X using package B should also receive the fix, because it would use the latest version of A dependency.

Is it possible and what should I do to achieve such behavior?

I tested a several ways that (kind of) worked. First I just first published the dependencies, then added NuGet package dependencies to the projects that used them. I mean the projects that were published later as packages. That worked, however it was awfully tedious to debug. A kind of a nightmare in fact.

Then I tested another approach - 2 kind of references varying between the Debug and Release configurations. The Debug configuration had the references to the projects, the Release configuration had the references to the packages. This is actually pretty manageable, however, the project files are pretty messy, it's all pretty complicated and still tedious to maintain.

I've read somewhere, that the .NET and NuGet will somehow solve it itself. I find it hard to believe. Is it THAT smart? Just leave normal configuration, references to the projects, and the packages will reference the corresponding packages if available?

Can anybody confirm or deny that?

There's a way to find out, publish the packages. But it's not exactly fully reversible. What goes to NuGet stays there forever. I can unlist those versions, but still it would take a lot of time to test it and it would create a mess.

Maybe somebody already tested this, or found some solid information about it.