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

RE: Testing of lsbdev and sample implementation

I think rsync was chosen as the sample application to test lsbdev because
it is one of the commands listed  by the LSB spec that needs to be on an
LSB compliant system. Since rsync needs rsh to do any client-side
operations, then it sounds to me like the LSB should add rsh to its command
list. Of course doing this opens up the same question for all the other
commands listed in the LSB. If any of them are like rsync and need a
command that is not in the LSB, then we need to find this out and handle
them accordingly. Hopefully, most of the commands will not be like rsync by
relying on the use of other commands instead of library calls.


Marvin Heffler
Linux Standard Base and Developers Toolbox
IBM Linux Technology Center
11400 Burnet Road, Zip 908-1A33
Austin, TX 78758
(512) 838-0953    T/L 678-0953

"Wichmann, Mats D" <mats.d.wichmann@intel.com> on 11/30/2001 01:36:07 PM

To:   Stuart Anderson <anderson@metrolink.com>, Marvin
cc:   lsb-impl@linuxbase.org, Chris Yeoh/Australia/IBM@IBMAU, George
      Kraft/Austin/IBM@IBMUS, lsb-impl@lists.linuxbase.org
Subject:  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...


-----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;
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.

To UNSUBSCRIBE, email to lsb-impl-request@lists.linuxbase.org
with subject of "unsubscribe". Trouble? Email

Reply to: