pkg_add vs. ssh

[Marc Espie <espie_(_at_)_nerim_(_dot_)_net>]

I think I've finally managed to get pkg_add working over ssh.
This turned out to be more complicated than I expected, so it warrants
a small explanation.

Basically, plain scp won't work correctly, because you don't control
when the fork'ed scp will die (well, you control when they die, but
the connection spawns more stuff, and that stuff tends to hang around)
=> big pkg_add operations, like -u, will tend to start grabbing lots of
files just to get to the PLIST, and abort the connection soon afterwards.

After much head scratching, I resorted to doing something rsync-like:
have just an ssh pipe, and communicate needed stuff between client and
server.

Since we're using perl, instead of needing a local copy of rsync on the
server, we can be much more devious: we just assume perl, and transfer
the server script on the pipe, first thing (using perl -x).

Then the client just asks for package listings (LIST directory), for
package contents (GET filename), or for early stop of a command (ABORT).

There was still one big problem left, which is that pkg_add doesn't
directly run the client, but runs a gunzip process which runs the client:
killing the gunzip doesn't ensure timely demise of the client process,
and I was left with a frequent deadlock, since the old client tended to
swallow the ABORTED answer from the server.

After more head scratching, I ended up using signal USR1 to communicate
between pkg_add and its client grand-child, to make sure this one was
done reading from the ssh connection before I did the ABORT and fired
the new connection.

The new code seems to work just fine so fine just far.