Hmpf. Rsync probably shouldn't have been chosen as a sample application for the reason that it calls external programs to handle the transfer (usually; there's a connect-to-rsync-server mode that I believe does not).
However, here's a question: can an LSB application call out to a non-LSB application "legally"? While it's doing so, /that/ usage isn't LSB-conforming, but does that make the application itself unable to be used as an LSB application? And... are there any plans for a dynamic application checker that could alert one to such issues, since a static checker can't find this sort of problem - it's not known until runtime which external program will be launched, since that's controllable by environment variable and/or command-line option. In fact, rsh and ssh could hypothetically be made part of the spec and rsync could still be called in a way that it lanuches yet another program that's not part of the spec... Mats -----Original Message----- From: Stuart Anderson [mailto:[EMAIL PROTECTED] Sent: Friday, November 30, 2001 11:42 AM To: Marvin Heffler Cc: [EMAIL PROTECTED]; Chris Yeoh; George Kraft; [EMAIL PROTECTED] Subject: Re: Testing of lsbdev and sample implementation Technically, if rsh isn't a LSB specified command, then it shouldn't be in SI, and an application shouldn't be calling out to it. Possibly, we need to add rsh (and ssh), but it should be added to the spec first.
