Subject: Re: anyone object to not having split sets in 1.4?
To: None <root@garbled.net>
From: John F. Woods <jfw@jfwhome.funhouse.com>
List: port-i386
Date: 04/03/1999 11:59:34
> On 02-Apr-99 Phil Nelson spoke unto us all:
> #  It might be nice if the script actually wrote to floppies.  Also, it
> #  would be nice if it generated a file that sysinst could read to determine
> #  how many parts were generated.
> Even nicer would be a dos .BAT file to do it as well, and maybe a pointer to
> some dos splitting utility.  Nethack used to ship with one.. It's presumably
> free.

I have written a Korn shell script to split the .tgz files and to generate
a file named "sets.txt" which contains lines like

kern ag
base bx
etc aa
comp bm
games am
man ar
misc aj
text af

The script does not currently assist in writing to floppies, because I
was working on it at 11:30pm and that was more work than I could cope with
at the time.  ;-)

If there's a desire to do the split under DOS, perhaps I should turn it into
a C program which can be supplied in DOS .exe format.  (I'm not certain offhand
if the DOS scripting language is powerful enough to handle the script I've
written, and I'm not dramatically interested in finding out...)

I have also coded changes to sysinst to have it prompt you for the floppy
containing "sets.txt" so that it can read it in and learn how many fragments
to expect; I will be testing that code later this afternoon.  It's reasonably
compact, though the way I've coded it right now requires changes to all the
md.h files; I should probably fix that.

Does that sound like a reasonable approach to everyone?  The downside I see
is that it absolutely requires you to add a file to the floppy set which a
new user might not immediately think to add; if a script or program is used
to assist in generating the floppies, however, it can add sets.txt to every
floppy (it's small, and there's plenty of room).

Alternatives which have occurred to me are:

1) Rather than the simple "press any key to admit you've inserted the floppy"
prompt, I could change it to be a menu with choices of "it's ready, read it"
and "there are no more fragments".  That would not be much more effort to use
than the current strategy.

2) Sysinst does a stat() on each chunk to determine that it exists.  That
also happens to tell it the size of the chunk; upon discovering that it has
read a short chunk, it knows that it has reached the last one.  This has
three problems:
* it assumes that all chunks are the same size, and someone, SOMEWHERE,
  probably thinks they have a good reason why they'd like some chunks to
  be shorter than others.  This is a problem that can probably be ignored.
* at least one .tgz file requires only one chunk, etc.tgz.  Either sysinst
  could mandate that the normal chunk size (235K) be the required chunk size,
  or it could be backed up with Alternative 1 above (since my original theory
  was that the size of chunk.aa would be used as the benchmark chunk size).
* if a .tgz file just happens to be precisely a multiple of the chunk size,
  nothing will flag sysinst that it has reached the end.  Again, Alternative
  1 could be used as a backup strategy, or the chunk generation program could
  detect that situation and generate an additional zero-length chunk.  (That
  leans more heavily on using supplied tools to generate the chunks rather
  than letting people just use "split" because they think they know what
  they're doing.)  The zero-length chunk could also solve the previous problem.

A relative drawback to the two alternative strategies compared with the
strategy I've implemented is that the sets.txt file could (potentially) also
contain a checksum of the assembled .tgz file:  currently sysinst does *no*
error checking in the assembly process, and floppies are not the most reliable
media (I've had one go bad in the process of generating my test set ;-).
The benefit of ensuring the data is correct might be worth the additional
hassle of having to keep track of a correct sets.txt file.

I've noticed, by the way, that architectures which don't support floppy
install sets *do* present the floppy option in the appropriate menu, yet
will crash with a NULL pointer dereference if you try it.  Is there any
reason to forbid (say) a VAX trying to use the floppy drive (if any), or
should I just insert a more friendly error message than "bus error -
core dumped"?