On Sun, Feb 13, 2011 at 10:08:07AM +0530, Joachim Breitner wrote: > Am Sonntag, den 13.02.2011, 05:26 +1030 schrieb Ron: > > I was tempted to make this an option, but given how hard it was to find > > a machine that didn't have rsync on it to run some tests, that sort of > > seems like overkill. How about the following patch then, which tries > > rsync first, then if that fails (because it's not available on the local > > or remote machine) just automatically falls back to trying scp. > > hmm, dcmd rsync might fail for many reasons (wrong password, host not > reachable), and doing this will cause it fail twice and annoy the user.
I think that's a valid concern, and was the main point in favour of making this a config option. I also considered whether we should try to trap some types of failure and handle them specially, but after testing some failure scenarios, the risk of 'user error' in the config solution, and of program logic error in the 'be clever about errors' case, would seem to pose a greater annoyance if hit than the duplicate failure actually seems to. > I think it would be fine to just expect rsync to be available. My main concern with that, is we potentially break things for existing users. And don't really give them any way to fix it but handhacking the script or changing their build system. (and your last set of fixes convinced me that not every user may have root on the build system to install rsync there on short notice :) The annoyance of that also seems greater than what I'm seeing if rsync chokes for a reason that would probably cause ssh to also fail too: The most annoying case would seem to be wrong-user or wrong-password. In that case you'll get prompted to enter the password repeatedly, but isn't really worse than the case where you forgot to pass -uc -us to a locally built package that you didn't want to sign. $ cowpoke foo_0.1.dsc nosuchu...@buildd.oz's password: ^C rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(543) [sender=3.0.7] nosuchu...@buildd.oz's password: ^C $ In the case of a similarly botched machine name, it fails instantly, and the duplication of errors is minimal: $ cowpoke foo_0.1.dsc ssh: Could not resolve hostname nosuchmachine.oz: Name or service not known rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7] ssh: Could not resolve hostname nosuchmachine.oz: Name or service not known lost connection In the case of a known machine that is down, it's much the same, with a small extra delay at the second attempt. It's still all basically over by the time you've had time to read the initial error report though: $ cowpoke foo_0.1.dsc ssh: connect to host unavailablemachine.oz port 22: No route to host rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7] ssh: connect to host unavailablemachine.oz port 22: No route to host lost connection I think the advantage of the fallback is that this will always work if it possibly can, and if there are people who don't have rsync, they'll get a nice little hint in the meantime that they could install it ftw. Sometime in the future we may drop it and have rsync only, but in the meantime, people it worked for yesterday will still find it working tomorrow too. Most of the failure modes where both will fail are the sort of thing that you'll get wrong once on initial install, then fix and never see them again until the next install. Anyhow, since jamessan asked some similar questions yesterday, I figured I'd put some rationale for what's been considered so far into the BTS, so if people see problems we haven't considered, or solutions we haven't thought of, then there's some background to consider them against. Cheers, Ron -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
