[lsb-discuss] potential lsb-apache FVT problem and /etc/services

Dan Kohn dan at dankohn.com
Wed Aug 23 07:46:46 PDT 2006


On Aug 22, 2006, at 8:01 AM, Theodore Y Tso wrote:

> The reason why I bring this is up is that one can posit a (badly  
> written)
> application which absolutely depends on getservbyname() returning a
> port number for "http", and where it bombs out if doesn't get
> a port number --- or a badly written shell script which assumes that
> getservbyport() will return "www" instead of "http", or vice versa.
> Such an application or shell script could be LSB certified, work  
> just fine
> on LSB certified distribution --- and then fail somewhere else.
>
> The question then is who is at fault?   Was it the LSB, for not
> specifying a controlled enough environment, or for not making the
> necessary admonition to the application writer (possibly refusing
> to certify it if we could determine that it is doing something
> non-portable)?   The ISV, for writing a bone-headedly stupid
> application?  The frustrated user, for having the expectation
> that an LSB certified application running on an LSB certified
> distribution should just work?
>
> This starts to edge into a philosophical discussion about what
> does LSB certification of an application mean, and whether or
> not we want to at some point in the future make claims of
> "write once, run everywhere" --- or has Sun and Java ruined
> that promise and made cynics of us all?   :-)

Hi, Ted.  My answer here is my own view, as Ian speaks for the FSG on  
technical issues.

First, Sun has forever turned write once, run everywhere into a term  
of derision.  So, if the FSG were going to target this approach, we  
would need to come up with a new slogan.

Anyway, my view is that since no one knows how to write provably  
correct large programs, no amount of testing is ever in principle  
comprehensive enough.  But, the more testing we do, we the  
asymptotically closer we can approach the ideal.  In this case, it's  
extremely unlikely we'd build a test by default to check for the  
boneheadedness you mention.  But, if a real-world LSB Certified  
application displays this level of boneheadedness, and this causes a  
failure on an LSB Certfied distro, I would expect the certified app  
to file a bug with the FSG.  In that scenario, I think it would be  
completely appropriate for the FSG to add a test case to cover this  
bug (presumably, by feeding different values to the application on  
multiple runs), rather than expecting the app vendor to fix their own  
bug without passing their learning on to the LSB community.

Now if your next point is that chroot and appchk do not give us the  
test frameworks we need to implement this bug test, then I would  
agree and say we may need an incremental app test framework.  I  
believe this is the point you were trying to make at the last board  
meeting.  Or, as Mats said, perhaps we could solve this solely by  
specifying what the certified distro should be returning to a  
function call.

            - dan
-- 
Dan Kohn <mailto:dan at dankohn.com>
<http://www.dankohn.com/>  <tel:+1-415-233-1000>




More information about the lsb-discuss mailing list