bug-inetutils
[Top][All Lists]
Advanced

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

Re: [bug-inetutils] Re: [PATCH] Inetd and test scripts


From: Alfred M. Szmidt
Subject: Re: [bug-inetutils] Re: [PATCH] Inetd and test scripts
Date: Fri, 05 Nov 2010 12:45:28 -0400

   > Now, ???netstat??? isn???t provided by Inetutils, so it???ll have to be
   > ???AC_PATH_PROG???d, and the test will have to be skipped if it isn???t
   > found.

   In my view a test program is not part of a software distribution.
   It is there to provide a tool, and a also a demonstration in what
   ways a piece of software has been tested, for the verification
   that the intended services behave as they were conceived.

I have to disagre to a point, any user who can install inetutils
should be able to run the testsuite.  If a specific program is needed,
then we should fail gracefully.

   You are right about skipping. Write a patch suggestion! The trivial
   one needs more context:

      test -x netstat  ||  exit 1

Can we get the info from netstat in another way, maybe implementing
netstat ourselfs?

       The very first issue of "tftp.sh" failed completely
   for OpenBSD. I had fixed that and submitted, only to find that this
   fix failed for FreeBSD and GNU/kFreeBSD once I booted such systems,
   so I had to proceed to mend that also.

The testsuite in IU is still very very basic, we will have problems
with it while we build it up.  It is very useful that we have NixOS
building, and running the tests due to its unorthodox configuration.
But even if it fails on NixOS, or anything else while we improve the
test suite that is fine; you cannot know if something breaks if you do
not know _if_ it breaks!  Thus, both Ludovics and Mats efforts are
indispensible in improving the test suite or any other part of IU.
   > For ???tftp.sh???, it doesn???t matter which one is failing.  It???s a 
tftp{,d}
   > test.  If something fails on the way, what matters is that the test
   > actually fails.

   I maintain my view point: It must at every time be possible to tell
   exactly why a test fail. Was it due to the object under test, or was
   it due to failer of the used tools?

I agree fully; what we can do is to seperate the common parts from the
tftp tests.  But it is the only test of any daemon/client
configuration we have currently, and things will have to grow from
that.

   > However, I agree that ???inetd??? alone should be tested as well.  
There???s
   > should be a different test for that, ideally a lower-level one, possibly
   > treating ???inetd??? as a white box.

   I agree again. Inetd must _also_ have its own test, but as long as
   the tests are written as individual entities, it misses the target
   to assume the correctness of each product of Inetutils that is being
   used as a tool in a test. On the other hand, any tool from the running
   OS should be assumed correct, but the test machinery must in an iterative
   process be used in as many possible environments that differing output
   from differing implementations be taken care of.

Agreed,

   > -$INETD "${VERBOSE:+-d}" "$INETD_CONF" &
   > +$INETD -d "$INETD_CONF" &

   I expected and I was hoping to get this question!

   This is tricky. Without "-d" the backgrounding fails, and the use of
   the process number "$!" fails. Without "-d" Inetd will go into the
   background itself, and the shell dash/bash/ksh/csh/tcsh will in "$!"
   report the process number of the process that the shell in question
   used to spawn the process, not the intended process number of "inetd".
   Remember my harsh talk about robustness?

Can we fix this? I haven't looked at the code for inetd, but I'd say it is a 
bug.

   I would very much welcome alterations to eliminate those irritating
   messages in [inetd] non-verbose mode, but I find myself having more urgent
   business to attend to.

Me too!  The test suite should spit all extra information into
seperate log files.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]