On Mon, Jan 4, 2010 at 11:10 AM, Martin Bligh <[email protected]> wrote:
> > That's probably a better place to do it. Or you can just do it directly > in > > abstract_ssh.py at the top level, although code which gets executed when > the > > module is imported is a little messy, even if it has the advantage of > just > > happening once, when things are loaded. > > Still, I'm of two minds about the automatic detection idea in general. > > There's no way to differentiate between rsync not being available when it > > shouldn't be, and it not being available when it should be; so you're > stuck > > with either being very noisy when it isn't available which is a problem > for > > setups where it's not supposed to be there, or you have to be quiet about > it > > being missing which makes it easy to overlook errors when it should be > > there. > > At least an explicit configuration option has the advantage of stating > the > > way things should be, so that the logging can be appropriately loud or > > quiet. > We could do a WARN (or even INFO) level message if rsync is not executable on the client (and, therefore, disabled for future transfers). Darin > > Understood, but we're getting a lot of config options which are making > install very complex at the return of dubious utility. We need to address > that. If we want to default things to automatic in general and provide > an option to force override if people really want to, that might be a good > way out. > > I still feel that server level is the wrong way to do this though, > it's a per-client > or at best per distro-type option. If you want to force a check back on or > off > based on what distro is detected, that might be OK. > > All that said; the way Darin proposed, you'd still get a log message for > the "problem", just not hundreds of them. I don't see a real downside?
_______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
