Initial LSB activities

[Dale Scheetz]

On 25 Aug 1998, Daniel Quinlan wrote:

> I would like the three sub-projects to start running now that they
> officially exist.  Here are some thoughts on where each group might
> begin work.  I don't believe any of these items is a waste of time.
> 
> My strategy is for us to begin with simple tasks, especially
> informational and exploratory tasks that encourage discussion between
> the three sub-projects.
> 
> Also note I am mailing the public list and only Cc'ing the private
> one.  My hope is that we'll have most of our discussion in the open,
> with non-members *lurking* as requested.
> 
> 1. Sample Implementation
> 
> Develop a list of source packages ABSOLUTELY required for ISV
> applications, including version numbers.  Try to move as many items
> from that list as possible into another list of nice-to-haves (that we
> will ignore for now).  For example, a compiler shouldn't be required
> to run most applications.
> 
> For example,
> 
>   - kernel 2.0.x (already on list)
>   - glibc 2.0.x (already on list)
>   - util-linux 2.x
>   - tar 1.11.8
>   - sh-utils-1.12
>   - gawk 3.0.0 (already "probably" on list)
>   - sed 2.05 (already on list)
>   - bash (for POSIX sh, which is already on list)

I have a problem specifying packages, and more of a problem specifying
fixed versions of those packages.

It is my expectation that the test suite will validate that the "programs"
required are available on the system, and that they will perform the
functions desired. This makes the version numbers unnecessary.

> 
> Only a list for now.  I think we should also worry if the list gets
> much longer than a few dozen items.  Also, I think we've pretty much
> decided that Perl is not on the list.
> 
> Each item should be scrutinized to make sure it's really needed.  Some
> items (like util-linux) will have a lot of stuff not needed, and maybe
> that should be documented.
> 
> Items left off the list aren't forbidden or ignored, just not part of
> the base that LSB-compliant software can really count on.
> 
> 2. Test Suite
> 
> More than one or two people should begin active work on existing Unix
> test suites.  We should at least find out where we stand with respect
> to POSIX, for example.  Initially, this will be just for our own
> information, but stands a reasonable chance of becoming part of our
> own testing.
> 
> We also need to determine if there are license problems with either
> NIST and TOG's POSIX test suites.  If there are, we need to decide
> what we could use, and what we want to use.
> 
NIST is public domain, TOG is prorietary.

I'm looking at the NIST suite now, and it looks like it will supply the
library testing that we need as well as several other POSIX issues. The
software seems poorly organized for our use, but, with a bit of work, can
provide the routines we need to test the library funtionality, and header
file contents and organization. As this is the "hardest" part of the test
suite, this will greatly speed the "time to target" for these tasks.

Thanks, 

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf at polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-