[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Testing of lsbdev and sample implementation



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:anderson@metrolink.com]
Sent: Friday, November 30, 2001 11:42 AM
To: Marvin Heffler
Cc: lsb-impl@linuxbase.org; Chris Yeoh; George Kraft;
lsb-impl@lists.linuxbase.org
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.



Reply to: