From owner-freebsd-hackers  Thu Sep 18 04:55:18 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id EAA01024
          for hackers-outgoing; Thu, 18 Sep 1997 04:55:18 -0700 (PDT)
Received: from word.smith.net.au (ppp20.portal.net.au [202.12.71.120])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA00980
          for <hackers@FreeBSD.ORG>; Thu, 18 Sep 1997 04:54:42 -0700 (PDT)
Received: from word.smith.net.au (localhost.smith.net.au [127.0.0.1])
	by word.smith.net.au (8.8.7/8.8.5) with ESMTP id VAA00568;
	Thu, 18 Sep 1997 21:20:25 +0930 (CST)
Message-Id: <199709181150.VAA00568@word.smith.net.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: nik@iii.co.uk
cc: Mike Smith <mike@smith.net.au>, hackers@FreeBSD.ORG
Subject: Re: Different kernels for the bindist and boot.flp? 
In-reply-to: Your message of "Thu, 18 Sep 1997 12:45:22 +0100."
             <19970918124522.57711@strand.iii.co.uk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 18 Sep 1997 21:20:21 +0930
From: Mike Smith <mike@smith.net.au>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > No, it's actually quite hard.  Due to the way the boot floppy works, 
> > you have to build a custom image with your new kernel, and then hack 
> > sysinstall to splat a new kernel image down after it's extracted the 
> > bindist.  You could alternatively specify a different kernel to go in 
> > the bindist, which is relatively straightforward but slow (you have to 
> > build a release to do it).
> 
> This is why I was thinking about seperating the bin dist into a bin dist and
> a kernel dist. The new bin dist contains everything non-kernel specific,
> the kernel dists each contain one kernel with support for a specific set of
> features, and the kernel config file used to create them.

This rapidly reduces to supplying the kernel sources and a text editor. 
The alternative is a million different kernel distributions, which are 
nothing short of a terror to maintain.

> Doing all this once, by hand, is probably not too difficult (I think it
> just needs lots of disk space to hold multiple copies of /usr/src for each
> different 'make release'.
> 
> Doing this so that the release engineer can do the equivalent of
> 
>      make -DDESTDIR=/releases/GENERIC -DKERNEL=generic
>      make -DDESTDIR=/releases/IDEZIP  -DKERNEL=idezip
>      make -DDESTDIR=/releases/NOSCSI  -DKERNEL=noscsi
> 
> (or similar) is another matter entirely.

It's already in place, insofar as the release will build as many 
kernels as you want.  You just have to refrob it to bundle them 
separately.

> > Oh, I meant hacking the release code 8)
> 
> Oh yes, that too. Did I delete the comment about needing eight pairs of
> hands to keep track of what's going where. . ?

No, I did.  I thought all us hackers were octopots?

mike

(Shirow fans are welcome to reply out of band.)