RE: Re: [Lsb-wg] Asserts and strategy for install_initd andremove_initd

 
>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?

So some comments here.  We're stuck with a situation
that isn't really testable.  install_initd is intentionally
an interface that hides implementation details, and many
of the details that are hidden are the ones that would
be needed to fully test (we will continue to try to
address that with lsbinstall, although of course that's
not a required part of the spec).

So the hope was to provide some minimal sanity checking
for systems that do use the most common scheme - the
sysv init scheme - and in some way flag the situation
for anyone else.  We're trying to avoid the situation
where initscript activation is just completely untested
in certification, I think experience shows that if we
bring people's attention to the area they will indeed
fix things up.  So what we were talking about yesterday
was that if the answer to an interview question is that
the sysv scheme is not supported, we have nothing to
test, but could hopefully issue a fip to get the
test operator to manually answer questions about whether
they support the initscript conventions.


>
>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?

It simulates it - we wanted to remove the package
installation aspects here, but invoke the same
steps that a package installation would.

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

>P.S. When does the review period end?

I don't even think they're claimed to be complete
at this point - more of a feedback period than
a formal review period.