Re: Proposal for building and nameing image options
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
Reply to: