cvs commit: src/release Makefile src/release/i386 mkisoimages.sh

Scott Long scottl at freebsd.org
Wed Jul 23 14:22:37 PDT 2003


Ruslan Ermilov wrote:
> On Wed, Jul 23, 2003 at 05:00:44PM -0400, John Baldwin wrote:
> 
>>On 23-Jul-2003 Ruslan Ermilov wrote:
>>
>>>ru          2003/07/23 13:53:37 PDT
>>>
>>>  FreeBSD src repository
>>>
>>>  Modified files:
>>>    release              Makefile 
>>>    release/i386         mkisoimages.sh 
>>>  Log:
>>>  Added the (undocumented) EMUL_BOOT variable (for TARGET=i386 only)
>>>  that causes the bootable ISO images to be created using the floppy
>>>  emulation (the old method) as opposed to the new "cdboot" method.
>>>  
>>>  Only copy boot.flp to the 2nd CD-ROM if this variable is defined.
>>>  
>>>  Reviewed by:    murray
>>
>>I would always copy the floppy.  The reason is so that all of the needed
>>bits for both boot types are available to vendors.
>>
> 
> Running "make release" with -DEMUL_BOOT but without -DMAKE_ISOS does
> just that.  My intent was for a standard "make release" to not have
> unnecessary bits.  There's no point in cdrom/disc2/floppies/boot.flp
> if we aren't even going to use it.
> 
> 
>>I can see vendors
>>taking the contents of an ISO, mounting it using mdconfig, adding more
>>bit in another dir, then using mkisofs to generate a new ISO with a
>>different boot method.  This would be done w/o rolling an entire release
>>but using the ISO from the Project's release.  In other words, I don't
>>think we should require vendors to roll an entire release just to use
>>boot.flp instead of cdboot or vice versa.  Please just leave both cdboot
>>and boot.flp on both ISOs.
>>
> 
> boot.flp is always available on the 1st disc in a set anyway; I don't
> see a problem copying it from here to the custom 2nd disc.
> 
> 
> Cheers,

I believe that John is asking for you to not limit the options that are
available, and also not require that a 'make release' is re-run to have
those options be available.  Whether or not *you* choose to use this
flexibility is not the point.  I think that John's position is quite
reasonable.

Scott



More information about the cvs-src mailing list