I want to make a NuGet package A that depends on NuGet package B.
Projects that will use package A will always have package B as a direct dependency.
Hence, I believe that package B does not need to be included inside package A.
Am I right? If yes, how to make that happen in PackageA.csproj? Also, how to specify the version range of package B that is acceptable for package A?
Hence, I believe that package B does not need to be included inside package A.
To be clear: we're talking about the Dependencies field of the nuspec/nupkg XML file, NOT about extra dll files in the lib/... directory of the output nupkg.
You don't need to, but in my opinion it's a good idea to do so anyways.
NuGet packages are just fancy Zip files containing the compiled dlls files. NuGet package A only contains the dll for project A, it doesn't (or, at least, it shouldn't) contain the dll for project B - that's why you have a NuGet package for project B.
When your client application (the one that uses NuGet packages A and B) compiles, A's dll is going to ask that B's dll is present. If you, as the developer, have manually added the NuGet reference for NuGet package B in the client application, everything should work out. You, however, are responsible for making sure it exists and the versions line up.
A real-world example for this is Hangfire and how it loads the database client for MS SQL Server. You have to manually add at least one of the options listed on that page, or it will complain at runtime.
Now, back to the "it's a good idea to do so anyways" comment. From the little I know about your project, it seems project A has a hard dependency on project B. If there isn't any sort of swapping of dlls (you could swap using NuGet B in the client application with NuGet C, and NuGet A will be happy using NuGet C's code instead), then I don't see a point of excluding the explicit dependency in NuGet package A.