The tpkg executable currently handles all of the local package operations as well as deployment to remote servers. The deployment functionality is rather different from the local package operation functionality in that it strips out any deployment-related command line options from the command line options that the user specified, then executes tpkg on the remote machines over ssh, replaying all the non-deployment options.
I haven't convinced myself one way or the other yet, but I think there's cause to believe we should move the deployment functionality to a separate executable (perhaps tdeploy?) The mechanism by which we strip out deployment-related options is fragile (see note in code comment for details) and would be hard to make robust. And more generally they seem like two different sets of functionality and having them in a single executable contributes to the overwhelming number of tpkg options and the general feeling that tpkg is too complex.
The tpkg executable currently handles all of the local package operations as well as deployment to remote servers. The deployment functionality is rather different from the local package operation functionality in that it strips out any deployment-related command line options from the command line options that the user specified, then executes tpkg on the remote machines over ssh, replaying all the non-deployment options.
I haven't convinced myself one way or the other yet, but I think there's cause to believe we should move the deployment functionality to a separate executable (perhaps tdeploy?) The mechanism by which we strip out deployment-related options is fragile (see note in code comment for details) and would be hard to make robust. And more generally they seem like two different sets of functionality and having them in a single executable contributes to the overwhelming number of tpkg options and the general feeling that tpkg is too complex.
Was: https://sourceforge.net/apps/trac/tpkg/ticket/47