Re: Install Cd's?

On Tue, 15 Apr 2008, Tom "spot" Callaway wrote:

> On Mon, 2008-04-14 at 12:24 -0400, Dean Anderson wrote:
> > You _have_ probably spent 6 months making
> > one build work for one distribution by tweaking the build machines and
> > build software.
> 
> I will only say this once more:
> 
> I DID NOT TWEAK THE BUILD MACHINES OR THE BUILD SOFTWARE.
>
> Not even a little bit. Not at all. I used rpmbuild inside of a chroot
> (where the tree RPM packages are installed) to generate the 2.99 RPM
> packages, then I used pungi to compose the tree into installable images.

Oh, but you did. Perhaps you didn't intend to--but intent has nothing to
do with it--I'm not criticizing your intent. I'm criticizing the
/insufficiently robust practice/ that led to the problem.  Your
'rpmbuild inside of chroot' is not sufficient to ensure a clean build
environment.

To review: you "tweaked" the build machines some time ago, when you
installed a kernel source package and then subsequently installed
another kernel source package that no longer contained the necessary
kernel sources, and had a conditional on the sources definition.  This
wasn't an "intentional" tweak, but it is a tweak nevertheless:  Because
the build machines still used sources to build the kernel which weren't
in the src.rpms. You didn't notice this problem until I tried to rebuild
the kernel src.rpm, and the rebuild failed because of a missing patch.
If your process and build machines were actually clean, YOU would have
noticed this problem before release.  

What this kernel source episode reveals is at least that you don't clean
out the SOURCES directory before a build; that means you aren't running
on a freshly built/installed machine, and so sources can be used which
aren't distributed.  Also, binary packages from previous aurora versions
can be used in the build which aren't documented because perhaps they
have been removed from the aurora distribution.  Bottom line is that you
don't start with a clean base when building. "rpmbuild with chroot"
doesn't cut it.  In the old unix terminology, "you didn't selfhost".

Selfhost is a process similar to what gcc does:

	1 build itself with foreign c compiler
	2 build itself again with gcc built by foreign c compiler
	3 build itself again with gcc built by gcc.

Selfhosting a release means you have to 

 1 build the distribution with a port machine (previous version maybe) 
 2 install that and build again. (build on linux built by previous
version)
 3 install that and build again. (build on linux built by same version)  
 4 test.

You are doing step 1 and calling it a release. That's going to
inevitably introduce source and binary issues similar to what we've
already seen.  I used to work on OSF/1, helping people port OSF/1. If
you don't selfhost and test, you absolutely WILL miss many problems. 40+
years of OS and compiler development has taught some lessons about how
to do these things.

> Pungi works out of the box on sparc, I wrote patches to enable support
> for sparc, sent them upstream, and they were applied.
> 
> This is the pungi.conf I'm using:

This pungi.conf is good. Can you put this on the website?

[details omitted in reply]

> Now, to answer your other items:
> 
> 1. Aurora 1.0 was a port of Red Hat Linux 7.3. Thus, the ancient
> instructions you found would have worked with it.

Yes. They were just an example. The point was there aren't any similar 
instructions for your current builds. 

> 2. I did not make any deviations on how SPARC bootable ISOs are created.
> Upstream mkisofs MADE THE CHANGE. Not me. I told you how I fixed the
> problem, by passing the proper flags, as documented in both mkisofs and
> silo (hint, it uses isofs.b). I patched pungi to do the right thing, as
> it is the Fedora compose tool, sent the patches upstream, upstream took
> them (this was months, maybe even a year ago).

My point is that these patches should have been on the aurora website a
year ago; when you made them and long before the upstreams took them,
because for a while those changes were specific to aurora and
unpublished.  

ANY LITTLE CHANGE YOU MAKE, NO MATTER HOW TRIVIAL, NEEDS TO BE
DOCUMENTED AND PUBLISHED.  And the change needs to be tested in clean
environment.  Things that work to build an operating system in a porting
environment don't always work in the built environment.

> 3. If you still have contentions, please, please, do a tiny amount of
> research before accusing me of things. I'm trying really hard to be
> patient with you, because I honestly have nothing to hide here, and I do
> want to ensure that there aren't things that I've gotten wrong.

I'm not accusing you of hiding anything with malice or bad intent.  
Primarilly its your process that is flawed, and its the process that
needs to be fixed.  

		--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   


_______________________________________________
Aurora-sparc-devel mailing list
[email protected]
http://lists.auroralinux.org/mailman/listinfo/aurora-sparc-devel
Aurora FAQ: http://www.ecs.soton.ac.uk/~mas01r/aurorafaq.html