Re: Proposal for building and nameing image options
stappers@stappers.nl (Geert Stappers) writes:
> 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
The resulting files will still differ. Floppy will be images with
floppy-retriever. Cdrom needs the cdrom-retriever and only one 2.88MB
floppy. Net needs the net-retriever and network modules with high
priority and has a size limit depending on the arch.
Now that I slept over it I see that "foreign" could be as floppy,
cdrom or net flavour. But floppy seem unlikely to be of use. But
foreign can probably stand the bloat of combining all three together.
> > 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.
A build system would call the target multiple times with all values of
NEXTMEDIUM.
> > 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.
It toggles between what is currently the businesscard image,
netinstall image and official images.
> > 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.
Actually its the opposite. With debian-cd its currently quite hard to
build small images and then you still have lots of bloat on them.
The current businesscard CDs are 48MB(iirc), without the bloat its 18MB.
> > 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
MfG
Goswin
Reply to: