Date: Sat, 27 Apr 2002 01:18:45 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: John Baldwin <jhb@FreeBSD.org> Cc: ru@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Makoto Matsushita <matusita@jp.FreeBSD.org> Subject: Re: cvs commit: src Makefile Makefile.inc1 src/etc Makefile src/ Message-ID: <20020427081845.GA328@dhcp01.pn.xcllnt.net> In-Reply-To: <XFMail.20020427002332.jhb@FreeBSD.org> References: <20020427033118.GA583@athlon.pn.xcllnt.net> <XFMail.20020427002332.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 27, 2002 at 12:23:32AM -0400, John Baldwin wrote: > > Now for a cross-release we need to make sure the binaries in /usr/obj > in the chroot are cross-built binaries. Ruslan's current approach is > to do this by make step 3 be a cross-buildworld instead of a full world. > This means, then, that any tools for the new world you need for 4 > need to be built as build-tools or cross-tools or the like. What I'm > suggesting is instead to insert a step at 3.5 to do a cross-build world > and then we still have the right tools installed and don't have to worry > about using the right build/cross tools for the release scripts. I'm trying to figure out what the implied problem is you're trying to solve. I think it's the following: o Compatibility between the release process and the tools it uses (including features of the tools it expects). This is indeed best solved by doing a full world to populate the cdroot a second time, but now with bits that match the sources. The tools and the release are guatanteed to be in sync. The drawback is that the new tools may not run on the machine. Take for example a change in libc that requires a new syscall. The currently running kernel may not have the new syscall. It's for this reason that the upgrade process installs a new kernel before installing world. Thus, a full world step 3 creates a more dangerous incompatibility than it's trying to solve. The approach Ruslan takes is AFAICT the right approach. Of all the possible incompatibilities, he leaves the incompatibility between the tools and the release process unsolved. This is the one developers can maintain by hand in a fairly straight- forward way and thus the safest one to ignore in the automation. Did I extract your concern correctly? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020427081845.GA328>