On Sun, Oct 12, 2003 at 04:12:52PM +0200, Goswin von Brederlow wrote: > Hi, > > this has been discussed a few times but we still have only the TYPE= > mechanism and some chaos. I propose to remove the TYPE= mechanism and > replace it with the following: > > >From the discussions I see that we have 3 parameters defining the > image to be build: > > 1. boot method > - floppy (floppy-usb, cdrom-boot-floppy via SBM, special usb-cdrom > boot floppy?) > - cdrom > - netboot (pxe, tftp) > - foreign OS (linux.bat under dos, amiboot under AmigaOS, yaboot > under MacOS, ...) > > 2. medium for udebs > - floppy (?) > - net > - cdrom / harddisk / partition > - loopback file (on cdrom / harddisk / partition) > > 3. amount of debs on the cdrom > - none > - base (+a few) > - all > > I propose the following scheme: > > 1. The "boot method" defines what kind of image we have to build > (togther with the arch). I suggest we use "BOOT=xxx" for that. > > I also suggest we add 2.88 MB floppy support to be used for the > cdrom bootimage. "BOOT=CDROM" would depend on "BOOT=floppy > FLOPPY_SIZE=2880". That should be just renaming some targets since > we already build such an image for TYPE=cdrom > > Floppy would be 1.44 MB (or 2.88 for cdrom boot) images dd'able to floppies. > Cdrom would be an iso9660 image (or hybrid for MAC). > Net would be a tftpimage. > Foreign would be a .tar.gz archive containing the bootloader, > kernel, initrd, startscript, icons/pif files. >
IMHO this can be reduced to FLOPPY_SIZE. When FLOPPY_SIZE=0 then there is a CDROM, USB-keychain, FS, NETWORK or whatever and no need to chunck it in parts of maxium size of FLOPPY_SIZE > 2. The "medium for udebs" defines the first retriever to be used and > the size of the image. I suggest "UDEBS=xxx" for that. > > Floppy support for udebs is probably useless given the number of > floppies needed. A subset of udebs to get networking running, like > ppp, pppoe or isdn might be feasbale though. > > Net would be like the "make cd_image TYPE=netboot" at the moment. A > real minimal CD just for booting and everything else from net. > > The last two can probably be merged into one case since they only > differ in how to detect the udebs. Its eigther directly on the FS > or the iso images is a file on the FS. This would be like the > businesscard CDs. > > Default for UDEBS should $(BOOT). > Please use 'NEXTMEDIUM' a value of 'cdrom' produces a binary with cddetect and cdrom retriever. a value of 'network' get a binary with ethdetect and net retrievers a value of 'floppy' has detectors and retrievers chunked in floppies a value of 'whatever' to show the modular concept. No default, the build system crunches then all, however keep it possible that a custom build of a single NEXTMEDIUM is possible. > 3. The "amount of debs on the cdrom" is only valid for "UDEBS=cdrom". > I suggest "DEBS=xxx" for this. > > Choosing DEBS=base on top of UDEBS=cdrom would add all base debs > to the cdrom and stuff like isdn and pppoe as long as we have no > udebs for that. > > Choosing DEBS=all would build a full cdrom set. > > The default for DEBS should be none. > I can't see what this option adds, seems like you wanna go beyond d-i, please elaborate. > > For the cd images debian-cd can be configured or patched to support such > an image and I think its wise to use it. Its practically a must for > DEBS=all type cdroms. I'm not sure, but it looks like "space enough on CD-rom, let's burn it!" Please keep d-i free from bloat. > > As for packaging and autobuilding images thats another questions and > should be discussed in a different thread. Please keep that out of > this thread unless its relevant. > > What do you think? With your proposal it is possible the build 1. stage and 2. stage images. > > MfG > Goswin > Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
