I have heard of some places that will drop pubs and Northwind. I never do. Too useful for testing stuff.
As for the DTS internals, I will take an ill-advised stab at explaining it all.
When you create a new DTS package, you are really creating a VB script which will do all the things that you told (not necessarily wanted) the DTS package to do. Technically, you could write a VB script in notepad to run a DTS package, but I already tried it. It stank.
The generated script is stored by default in the msdb database (sysdtspackages), but can be stored as a VB script, a proprietary DTS formatted file, or in the SQL Server metadata repository (have not touched that, myself).
A VB script version could be run on any windows machine, but will promptly choke, if it can not find the .dlls in order to get all the fancy functions it needs.
Actual package formatted DTS packages (from msdb, Metadata, or the proprietary file format) can all be run by the dtsrun.exe utility. This is what SQL Agent calls, when you schedule a package to run. It also happens to be the same executable that Enterprise Manager calls to run a package for you on your laptop. This is where the client dependencies start. If you have a SQL 2000 Enterprise Manager, you can run your package locally no problem. When you try to run the "same" package via SQL Agent on a SQL 7.0 server, you get nothing but errors. This is because you have asked the script to created with one library, and run with a separate library, and your package has only one library card (sorry, it is past 5:00).
So, now that you are no doubt utterly confused, the answer is "No, Enterprise Manager does not have to be running, but SQLAgent has to be running (in order to spawn the process), the dtsrun.exe utility has to be there (it is for any SQL Server install), and the dts*.dlls have to be there, and be the right version." Clear as mud?