Re: [Lsb-wg] Asserts and strategy for install_initd and remove_initd
Andrew Josey <[email protected]>
| Newsgroups | gmane.linux.lsb.test-suite |
|---|---|
| Message-ID | <[email protected]> |
Gordon, All I've cc'd lsb-test. Some global comments, we need to see some references in the assertions , 1 to identify the part of the specification they relate to for traceability, and 2 to be able to embed that in the test so we can tell which assertion a test is testing. For example I think this is testing this part of the spec 20.4. Installation and Removal of Init Scripts but I should not need to have to work this out, this information should be provided with the assertions! I'd suggest each assertion be minimally numbered 20.4-1 20.4-2 etc What happens if the scheme is not similar to the System V Init mechanism? How similar does it need to be? If not similar will these test cases return UNTESTED/UNSUPPORTED? Are you sure that the test strategy that does a copy of the scripts into /etc/init.d will work across all platforms? The spec states: An init script shall be installed in /etc/init.d (which may be a symbolic link to another location), by the package installer. The spec does not define what "the package installer" means. Does copying a init script constitute the action of a package being installed by the package installer? Does an implementation that only supports scripts installed through rpm or some-other-package-installer tool not comply? So you may want to thing about making the "copy scripts into /etc/init.d" part into an implementation under test supplied part. Your asserts look very general, and do not give much clues as to what they are testing or how The spec has words such as: Example: if an init script specified "Default-Start: 3 4 5" and "Default-Stop: 0 1 2 6", install_initd might create "start" symbolic links with names starting with 'S' in /etc/rc3.d, /etc/rc4.d and /etc/rc5.d and "stop" symbolic links with names starting with 'K' in /etc/rc0.d, /etc/rc1.d, /etc/rc2.d and /etc/rc6.d. Such a scheme would be similar to the System V Init mechanism, but is by no means the only way this specification could be implemented. This looks testable if a SysV Init scheme is implemented and should be explicit assertions.If not testable then its ok for assertions to state that an aspect of the spec is untestable. regards Andrew P.S. When does the review period end? On Jun 14, 3:09pm in "[Lsb-wg] Asserts and", McFadden, Gordon wrote: > > Please review. > > Asserts and strategy for install_initd and remove_initd > V1.1 > > > >># This test case assume a SYSV init inmplemenation > >># There will be two init scripts. Each should be installed as > >># start scripts in 1,3,5 and stop scripts in 0,2,4,6. > >># Since there is an assumption that this is being executed on a > >># a SYSV init system, then init scripts should exist in /etc/init.d > >># and we will provide an environment path for the parent directoy of > rc0.d > >># through rc6.d > >># > >># There will be 5 tests cases as follows, with the following > attributes: > >># initA will have no dependencies. > >># initB will depdend on initA > > >>ASSERTION Good A > >> install_init will install an init script > > >>STRATEGY > >> The system will be verified clean, the install script initA will be > copied > >> from the scripts directory to /etc/init.d and then install_initd will > be > >> invoked. The appropriate rcn.d directorys will be examined to ensure > >> placement of the start and stop scripts. > > >>ASSERTION Good B > >> install_init will install an init script that depends on another > script > >> already being installed. > > >>STRATEGY > >> The system will be verified clean, the install scripts initA and > initB > >> will be copied > >> from the scripts directory to /etc/init.d and then install_initd will > be > >> invoked first for initA and then for initB. The appropriate rcn.d > >> directories will be examined to ensure placement of the start and > stop > >> scripts. > > >>ASSERTION BAD A > >> install_init will not install an init script if the scripts depends > on > >> another script which is not installed. > > >>STRATEGY > >> The system will be verified clean, the install script initB will be > copied > >> from the scripts directory to /etc/init.d and then install_initd will > be > >> invoked. The appropriate rcn.d directories will be examined to > ensure > >> placement of the start and stop scripts. In this case, there should > be > >> no start and stop scripts for initB and the return value should be 1. > > >>ASSERTION Good A > >> remove_init will un-install a script > > >>STRATEGY > >> The system will be verified clean, the install script initA will be > copied > >> from the scripts directory to /etc/init.d and then install_initd will > be > >> invoked. The appropriate rcn.d directories will be examined to > ensure > >> placement of the start and stop scripts. the remove_initd will be > invoked > >> to un-install the script. The relevant directories shall be examined > to > >> ensure no start and stop directories exist in the rcn.d directories. > > >>ASSERTION Bad A > >> install_init will not un-install an init script if there is a > different > >> package depending in this script. > > >>STRATEGY > >> The system will be verified clean, the install scripts initA and > initB will > >> be copied > >> from the scripts directory to /etc/init.d and then install_initd will > be > >> invoked for first initA and initB. The appropriate rcn.d directories > will > >> be examined to ensure > >> placement of the start and stop scripts. remove_initd will then be > invoked > >> to attempt to un-install initA. This should fail, return 0. All > start > >> and stop scripts should remain unchanged. > > > -- > Gordon McFadden > System Architect > Channel Software Operation > Intel Corporation > ph: +1 503 264 4309 > [email protected] > > _______________________________________________ > Lsb-wg mailing list > [email protected] > http://mail.freestandards.org/mailman/listinfo/lsb-wg >-- End of excerpt from McFadden, Gordon