Date: Thu, 3 Mar 2011 14:52:51 -0700 From: Scott Long <scottl@samsco.org> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r219181 - head/release Message-ID: <C2F1B6E5-7ECB-490C-A464-BC869ED84A3B@samsco.org> In-Reply-To: <4D700B2D.1010003@freebsd.org> References: <201103021606.p22G6vou020460@svn.freebsd.org> <201103031209.43857.jhb@freebsd.org> <4D6FCE64.3010302@freebsd.org> <201103031432.36336.jhb@freebsd.org> <F4365559-D893-44D8-8AD3-C56276BE14C4@samsco.org> <4D700B2D.1010003@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 3, 2011, at 2:42 PM, Nathan Whitehorn wrote: > On 03/03/11 15:14, Scott Long wrote: >> On Mar 3, 2011, at 12:32 PM, John Baldwin wrote: >>> On Thursday, March 03, 2011 12:22:44 pm Nathan Whitehorn wrote: >>>> On 03/03/11 11:09, John Baldwin wrote: >>>>> On Wednesday, March 02, 2011 11:06:57 am Nathan Whitehorn wrote: >>>>>> Author: nwhitehorn >>>>>> Date: Wed Mar 2 16:06:57 2011 >>>>>> New Revision: 219181 >>>>>> URL: http://svn.freebsd.org/changeset/base/219181 >>>>>>=20 >>>>>> Log: >>>>>> Add additional release makefile for bsdinstall-based media, = along with >>>>>> support files. This does not change the default behavior of = anything. >>>>>>=20 >>>>>> To make bsdinstall-based media, pre-build world and GENERIC, = then run >>>>>> the release target in Makefile.bsdinstall. >>>>> Are you planning on keeping the current 'make release' behavior of = building a >>>>> full chroot and doing a clean build in the chroot to build a = release? That >>>>> is, is 'Makefile.bsdinstall' just a temporary shortcut for = building test >>>>> releases or is that the final replacement for 'release/Makefile'? >>>> It was intended (modulo memstick building, docs, and some = miscellaneous >>>> cleanup) to be the final replacement for release/Makefile. In my >>>> experience, the automatic fetching, clean build, and chroot was a = major >>>> impediment to easily making installation media for users to test >>>> patches. I figured that if people (e.g. re@) really want a totally = clean >>>> tree, checking one out by hand and building from there didn't seem = like >>>> an enormous obstacle. >>>>=20 >>>> If you think it's a really important feature, I'm happy to add it = back, >>>> however. >>> I think it is a very important feature to ensure release builds are = not >>> polluted by local changes in /etc/src.conf, etc. I think it would = be good >>> to support both models perhaps, but for our official release builds = I think >>> we need the clean environment. I certainly use 'make release' now = for my >>> own custom FooBSD builds to get a clean environment. >>>=20 >> Agreed entirely. I'd consider it a major bug if the insulated = release environment went away, especially since I'm switching release = building at Yahoo to use it. There are plenty of shortcuts available in = the script to reduce the time overhead for quick turnaround testing. >=20 > To me, there's a distinction between "release building" and "make = bootable media", and I like the suggestion to support both. One option = would be that we keep the "make cdrom" target as is, but add = dependencies, and then have a "release" target that actually the chroot = setup. Another would be to keep the Makefile as-is, but to add a shell = script that does the version control checkout, building, chroot setup, = etc., etc. Would you have a preference there? > -Nathan I've been using the existing /usr/src/release/Makefile for 10 years, so = it's pretty ingrained in me; I'm reluctant to embrace change =3D-) That = being said, yeah, I can see how there can be some improved = modularization between obtaining the src tree, setting up the chroot, = generating object bits, and packaging those bits onto release media. = Those functional splits already exist within the Makefile, but probably = aren't too clear unless you're very familiar with all of the sub-targets = and control variables. If you wanted to clean this up and provide some = clearer modularization, I think it could be a good thing. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C2F1B6E5-7ECB-490C-A464-BC869ED84A3B>