Fair enough! I thought that that might have been the case, I believe. 
Ah, you’re right. I just ran the “rtdist” build again, and now that it’s failed, I see that the message just before the traceback reads as follows:
Generating twisted/thaumaturge_1.9/linux_amd64/twisted.thaumaturge_1.9.linux_amd64.mfLooking that up, I see that it’s a networking framework–for which the inclusion of something called “urllib” makes sense, I daresay.
I recall that Panda3D uses a client-host approach to distributing games–even self-contained installers retrieve elements from one or more sources while building. As a result, this might not be safe to omit.
On the other hand, the issue seems to only show up in the “rtdist” build–the “runtime” and SDK builds seem unaffected. As such, perhaps it’s only used for game-level networking, in which case perhaps it is safe to omit, given that I’m making an offline-only single-player game?
I take it that the “stage” directory is created as part of the build process, then? And should the same directory (as opposed to the “_rt” version) be used when building the runtime?
Hum… So what determines the host referenced in the .p3d file? I don’t see an option for that in packp3d…
That does sound good! I’m a little shy of risking a new and untried deployment system as things stand (especially since I do want this game to be commercial, eventually), but if deploy-ng proves sufficiently stable and effective I may well end up switching over to it.