Subject: Re: 1.2-release/inst-12.fs corrupt, unable to install base
To: Kjetil Bernhard Thomassen <thomassk@oslo.geco-prakla.slb.com>
From: Mark Brinicombe <amb@physig4.ph.kcl.ac.uk>
List: port-arm32
Date: 10/29/1996 19:18:05
>Also, when I ran gunzip there was no action whatsoever. This
>indicated that something is wrong.
I'll look into this.

>I then booted with the 1.2-beta/inst-12.fs.gz floppy and checked
>the gunzip there. That was ok. Also, I checked the inst script
>on that floppy and found that egrep was not used.

The 1.2-release inst script does use egrep. A symbolic link from egrep to grep
was missing.

>So, the conclusion is: Use the 1.2-beta/inst-12.fs.gz file to
>install the 1.2-release until someone (Mark?) fixes the floppy
>for the 1.2-release.
Reasonable.

>I ask myself how this could have happened, and I can only think
>of one reason. The person (Mark?) who made the 1.2-release
>installation floppy has not done a new installation with this.
Yep screw up time again. The rational was that
1. I did not have a spare HD at the time.
2. Time was critical and I really needed to get it out
3. The only change was to the inst script should be no problems.
4. I was doing it in the middle of the night.

Anyway sorry, I should have properly tested it first.

>I also do not think that it is wise to call such a "all commands
>in one program"-program for /bin/cat. It should have been called
>/bin/all_commands or something else so that one does not conclude
>like Kim: "All programs is /usr is only cat, no wonder that it
>does not work." I also had the same conclusion until I saw that
>the 1.2-beta/inst-12.fs.gz floppy had the same. Then I did a
>compare of the two cat's and found that they were different.
>That was what triggered me to try the cat on the 1.2-beta floppy.

All the binaries that appear as links to /bin/cat are all compiled into
one binary so that only 1 copy of libc et al. is needed.
The actual name does not matter. There is a front end that examines the name it
was invoked with. The file is actually called /bin/cat as that is the first
file installed on the floppy image when building.

This is only used during this initial stage as when base is installed it will
replace all the binaries including /bin/cat with the real ones.

>There has just been too many problems like this, so I think
>we need to establish some better testing procedures before
>releasing software. Too many man-hours are wasted trying to
>fix problems that shouldn't have been there in the first place.
Yep I agree. I would be happy for someone to suggest solutions.
At the moment I build the release, test install it, test run it etc.
In alot of situations (e.g. programming) the person that creates a program is
not the best person to find the bugs. Often there may be things that I take for
granted that someone will or will not do and this can cause problems if I have
not anticipated everything.
Also for me time is a major factor. It is far quicker for me to build a release
than to test it properly. To test it I need a spare big disc to do a complete
installation and then really I should run with that installation for a week or
two. However due to development my machine is not a good test platform for
stable releases.

This raises various Q's about the release build procedure and testing
procedure.

Currently I rebuild every package for the release and then every package needs
testing. If a new version of source is available then I pull that, have to
spend time patching it etc. then testing it.
For example for each release I need to test *every* binary that is in the
release. How ?
What I need are a set of scripts that will exercise every single command.
I have come across cases where obscure commands had problems. In fact there are
several commands I recently found that can generate SEGV's in the 1.2-beta base
set, however I don't expect anybody to have ever used those commands. (A
rebuild of the binaries fixed the problem.)

Should I perhaps build the release and make it available to a small group for
testing  prior to final release ? Who would be perpared to test every release
 / upgrade ?

THis is something that needs to be sorted and I would welcome any suggestions.

Cheers,
					Mark

-- 
Mark Brinicombe				amb@physig.ph.kcl.ac.uk
Research Associate			http://www.ph.kcl.ac.uk/~amb/
Department of Physics			tel: 0171 873 2894
King's College London			fax: 0171 873 2716