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